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^The  Defense  Integrated  Data  System  (DIDS)  at  the  Defense  Logistics  Services 
Center  (DLSC)  is  designed  to  provide  logistics  data  services  for  logistics  man- 
agers in  various  functional  areas.  DIDS  is  designed  to  make  the  logistics  man- 
agement of  defense  items  more  effective  through  centralized  processing  of  the 
workload,  rapid  response  to  inquiries,  and  exhaustive  screening  of  logistics 
data  to  maximize  the  utilization  of  current  inventory  items  and  reduce  the 
introduction  of  redundant  items  into  the  inventory.  The  DIDS  computer  system 
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IS  a large  scale,  centralized,  multiprocessor  system  that  utilizes  a functionally 
integrated  data  base  of  some  8 billion  characters,  and  processes  about  2.5  million 
transactions  monthly.  It  includes  two  Burroughs  6700  computer  systems  and  one 
IBM  360/65J  computer  system 

DIDS  is  experiencing  difficulties  meeting  current  workload  requirements, 
and  there  is  growing  concern  over  its  efficiency  and  capacity.  In  view  of  these 
difficulties,  a request  has  been  submitted  to  augment  DIDS  computer  equipment 
to  alleviate  both  current  and  near-term  capacity  limitations. 

This  study  assesses  whether  the  additional  hardware  requested  would  solve 
the  alleged  DIDS  efficiency  and/or  capacity  problem,  or  whether  the  present 
hardware  is  adequate,  but  must  be  utilized  more  effectively.  A The  current  DIDS 
computer  configurations  are  described,  their  capacity  to  process  the  existing 
and  projected  workload  determined,  and  the  apparent  causes  of  \he  processing 
limitations  identified.  Five  options  for  eliminating  these  constraints  are 
assessed  for  their  feasibility,  practicability,  potential  for  relieving  capacity 
constraints,  and  approximate  costs. 
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The  ability  to  assess  complex  computer-based  information  systems  is  critical  to 
their  management  and  review.  The  larger  and  more  complex  the  EDP  system  and 
automated  applications,  the  more  difficult  it  is  to  assess  their  performance.  The  Defense 
Integrated  Data  System  (DIDS)  is  a large-scale,  functionally  integrated  data  system  with  a 
direct  access  data  base  of  about  8 billion  characters. 

The  study  was  carried  out  under  LMI's  contract  with  the  Office  of  the  Assistant 
Secretary  of  Defense  (Manpower,  Reserve  Affairs  and  Logistics),  at  the  request  of  the 
Director  for  Supply  Management  Policy.  Its  purpose  is  to  provide  insights  useful  to  the 
management  review  of  DIDS.  Because  of  time  constraints,  the  study  was  carried  out  in 
one  month.  The  nature  of  the  analysis  called  for  an  eclectic  set  of  skills  in  EDP 
performance  analysis,  management  information  system  design  and  evaluation,  and 

j 

organization  analysis.  Few  individuals  are  proficient  in  all  these  skills;  indeed  few  | 

organizations  can  field  a team  with  such  expertise.  Our  approach  was  to  assemble  a team  j 

from  LMI,  consultant  and  subcontractor  personnel.  The  use  of  the  team  approach  for  this  i 

i 

short  and  intensive  effort  proved  to  be  very  effective.  { 

Even  though  the  study  focuses  on  a few  selective  questions,  we  feel  that  the  nature  | 

of  the  task,  the  approach  taken  and  the  fact  that  we  could  successfully  perform  an  | 

intensive  four-day  EDP  audit  of  a large-scale  computer  system  should  be  of  interest  to  j 

managers  and  analysts  concerned  with  such  systems.  These  kinds  of  analyses,  particularly  | 

for  large-scale  systems,  are  not  straightforward  efforts.  They  can  and  should  be 

( 

1 

approached  systematically.  Their  success,  however,  is  dependent  upon  many  qualitative  I 
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The  Defense  Integrated  Data  System  (DIDS)  at  the  Defense  Logistics  Services 
Center  (DLSC)  is  designed  to  provide  logistics  data  services  for  logistics  managers  in 
various  functional  areas.  DIDS  is  designed  to  make  the  logistics  management  of  defense 
items  more  effective  through  centralized  processing  of  the  workload,  rapid  response  to 
inquiries,  and  exhaustive  screening  of  logistics  data  to  maximize  the  utilization  of  current 
inventory  items  and  reduce  the  introduction  of  redundant  items  into  the  inventory.  The 
DIDS  computer  system  is  a large-scale,  centralized,  multiprocessor  system  that  utilizes  a 
functionally  integrated  data  base  of  some  8 billion  characters,  and  processes  about 
2.5  million  transactions  monthly.  It  includes  two  Burroughs  6700  computer  systems  and 
one  IBM  360/65J  computer  system. 

DIDS  is  experiencing  difficulties  meeting  current  workload  requirements,  and  there 
is  growing  concern  over  its  efficiency  and  capacity.  In  view  of  these  difficulties,  a 
request  has  been  submitted  to  augment  DIDS  computer  equipment  to  alleviate  both 
current  and  near-term  capacity  limitations. 

This  study  assesses  whether  the  additional  hardware  requested  would  solve  the 
alleged  DIDS  efficiency  and/or  capacity  problem,  or  whether  the  present  hardware  is 
adequate,  but  must  be  utilized  more  effectively.  VVe  first  describe  the  current  DIDS 
computer  configurations,  determine  their  capacity  to  process  the  existing  and  projected 
workload,  and  identify  the  apparent  causes  of  the  processing  limitations.  We  then  discuss 
options  for  eliminating  these  constraints  and  assess  their  feasibility,  practicability, 
potential  for  relieving  capacity  constraints,  and  approximate  costs. 

DIDS  COMPUTER  RESOURCES 

Primary  B6700 

The  critical  DIDS  resource  is  the  Primary  B6700.  Only  that  system  has  direct  access 
to  the  Total  Information  Record  (TIR).  As  currently  operated  and  configured,  the 
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Primary  B6700  is  processor  (CPU)-bound.  It  has  the  maximum  number  (three)  of  Central 
Processing  Units  (CPUs)  for  B6700's,  and  is  near  the  limit  on  physical  device  addresses  and 
physical  I/O  connections. 

We  estimated  that  the  Burroughs  Master  Control  Program  (MCP)  and  Data 
Memagement  System  (DMS)  consume  between  25%  to  40%  of  the  CPU  resources  on  the 
Primary  B6700.  In  other  words,  on  the  average,  almost  one  out  of  the  three  CPUs  is  not 
available  for  processing  application  programs.  For  other,  typically  smaller,  B6700 
applications,  the  MCP  and  DMS  overhead  requires  about  20%  of  the  CPU  resources.  The 
application  programs  on  the  Primary  B6700  consume  about  60%  to  75%  of  the  CPU 
resources. 

The  Primary  B6700  presently  has  no  peripheral  memory  or  I/O  contention.  The 
usable  peripheral  mass  storage  capacity  is  estimated  to  be  about  11  billion  characters. 
The  present  DIDS  data  base  is  about  8 biUion  characters. 


Secondary  B6700 

As  currently  configured,  for  testing  application  programs,  the  Secondary  B6700  is 
core  (memory)-bound.  The  two  CPUs  on  this  system  are  utilized  about  50%  of  the  time. 
In  other  words,  one  half  of  the  time  the  CPUs  are  idle.  We  observed  no  I/O  contention  on 
the  Secondary  B6700. 

The  proposed  hardware  augmentation  would  double  the  current  core  (memory),  and 
more  than  double  the  disk  and  tape  storage  devices.  The  number  of  CPUs  would  remain 


IBM  360/65J 

T’lis  computer  was  not  closely  examined  because  it  did  not  have  any  apparent 
bottlenecks.  The  IBM  360/65J,  with  the  Storage  Technology  Corporation  (STC)  high 
speed/capacity  tape  drives,  has  sufficient  processing  and  storage  capacity  for  the 
proposed  Alternate  Relocation  Site  (ARS)  processing,  although  requirements  for  fourth 
quarter  publication  apparently  cause  temporary  saturation  or  capacity  deficits. 
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DIPS  FILE  DESIGN 

The  TIR  file  organization  is  effective.  The  National  Item  Identification  Number 
(NUN)  is  used  as  the  physical  address  in  the  direct  access  memory.  The  cross-index  (part 
number)  file  is  not  as  effectively  organized.  Approximately  24%  of  the  daily  transactions 
for  inquiries  do  not  have  a NUN,  and  require  access  to  this  cross-index.  That  24%, 
however,  accounts  for  about  47%  of  the  I/O  time  required  to  process  all  the  daily 
transaction  inquiries. 

DIPS  WORKLOAD 

There  are  now  processing  backlogs  for  several  DIPS  functions.  Additional  functions 
have  already  been  scheduled,  but  not  implemented,  thus  intensifying  the  issue  of  workload 
saturation.  This  analysis  assumes  the  DIPS  workload  projections  prepared  in 
December  1976  by  DLSC  and  DLA.^ 

By  December  1977,  the  overall  DIPS  workload  volume  is  expected  to  have  increased 
10%  over  the  January  1977  figure.  Projected  increases  for  each  EDP  system  are  shown  in 
Table  S-1. 

TABLE  S-1.  WORKLOAD  PROJECTIONS  BY  EDP  SYSTEM 


Source:  DLSC  DIPS  Workload  Projection^  based  on 
wan  clock  hours,  December  1976."^ 

^Since  this  study  it  has  been  pointed  out  by  DLSC  and  DLA  that  their 
December  1976  workload  projection  was  not  complete  because  several  workload  areas 
were  not  quantifiable  at  that  time.  A discussion  of  the  possible  additional  workload 
magnitudes  and  its  implications  for  the  study  results  is  given  in  Appendix  B of  the  report. 

The  brevity  of  the  study  precluded  the  computation  of  DIPS  workload  and  EDP 
capacity  estimates  in  terms  of  CPU  processor  hours.  Consequently,  we  used  the  DLSC 
estimates  based  on  wall  clock  hours,  which  are  not  as  appropriate  as  processor  hours. 


Computer  System 

Projected  Workload  Increase 
By  12/77  Over  1/77 

Primary  B6700 

10% 

Secondary  B6700 

2% 

IBM  360/65J 

19% 
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The  DLSC  DIDS  December  1976  workload  projection  shows  no  increase  in  1978  or 
1979  over  the  projected  levels  for  end  of  the  year  1977.  Assuming  that  the  DLSC 
projections  are  accurate,  if  the  1977  year-end  workload  levels  can  be  accommodated,  the 


following  two  years  can  also  be  accommodated. 

EDP  CAPACITY  VERSUS  PROJECTED  WORKLOAD 

The  estimated  differences  between  the  current  (January  1977)  DLSC  EDP  capacity 
and  the  projected  DIDS  workload  requirements  by  year-end  1977  are  tabulated  in 
Table  S-2.  These  projections  are  based  on  DLSC  wall  clock  hour  estimates. 


TABLE  S-2.  DIFFERENCES  BETWEEN  CURRENT  EDP 
CAPACITY  AND  raOJKCTET?  "WORKLOA'D ' REQUIREMENTS 


Current 

Projected 

(1/77) 

(12/77) 

Primary  B6700 

+ 0.2% 

- 9.7% 

Secondary  B6700 

- 3.6% 

- 4.8% 

IBM  360/65J 

+11.3% 

- 5.8% 

Source;  DLSC  DIDS  Workload  Projections 
based  on  wall  clock  hours, 
December  1976. 


The  Primary  B6700  is  virtually  saturated  and  will  have  a capacity  deficit  of  about  10%  by 

the  end  of  1977.  The  Secondary  B6700  is  now  saturated.  Its  capacity  deficit  in 

January  1977  was  about  4%,  and  it  is  expected  to  grow  to  about  5%  by  December  1977. 

The  IBM  360/65J  presently  has  a capacity  surplus  of  about  11%,  but  is  projected  to  have  a 

deficit  of  about  6%  by  the  end  of  the  year.  We  did  not  analyze  the  IBM  360/65J  workload 

projections  carefully,  but  its  end  of  the  year  deficit  is  apparently  related  more  to  the 

publications  scheduled  for  the  fourth  quarter  than  to  growth  in  the  daily  workload. 

ESTIMATION  OF  WORKLOAD  TRANSFERABLE  FROM  THE  PRIMARY  B6700 
TO  THE  SECONDARY  b6700 

Based  on  two  separate  efforts,  we  estimate  that  about  85  hours  of  processor  time 
per  month  could  be  transferred  from  the  Primary  B6700  to  the  Secondary  B6700.  This 
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amounts  approximately  to  an  additional  5.8%  to  7%  of  processor  capacity  that  would  be 
available  per  month  for  processing  application  programs  on  the  Primary  B6700. 
WORKLOAD  SCHEDULING  AND  APPLICATION  PROGRAM  PROCESSING 

Considerable  processing  is  required  for  the  application  programs  to  access  the  TIR, 
because  of  interface  inefficiencies,  limited  asynchronous  processing,  and  variable  length 
fields/records  not  handled  effectively  by  the  B6700  software.  Workload  scheduling  of 
transactions  is  now  done  manually,  and  the  use  of  checkpoints  for  potential  recoveries 
limits  throughput,  particularly  on  the  Primary  B6700.  The  preemptive  introduction  of  high 
priority  (levels  1 and  2)  transactions  in  inefficient  queue  lengths  into  the  workload  stream 
disrupts  the  work  flow  and  reduces  the  throughput  volume. 

OPTIONS  FOR  IMPROVING  DIPS  PROCESSING  CAPACITY 

We  considered  five  options  as  candidate  solutions  to  the  current  constraints  on  DIDS 
processing  capacity.  They  were  assessed  for  their  feasibility  (Is  it  possible?), 
practicability  (WiU  it  work  weU?),  and  relative  cost.  No  detailed  cost  benefit  analyses 
were  performed,  and  no  options  entailing  equipment  incompatible  with  the  current 
hardware  were  considered.  The  options  and  their  assessment  follow: 

Option  One  - Maintenance  of  the  Status  Quo 

The  EDP  systems  could  be  left  as  they  are,  with  little  or  no  software  and  application 
program  optimization.  The  current  workload  congestion  would  continue  and  probably 
worsen,  because  of  the  saturation  of  the  Primary  B6700.  Maintenance  of  the  status  quo  is 
feasible  (DLSC  is  basically  operating  this  way  now),  but  it  is  not  judged  pr-'cticable  by 
either  DLSC  or  DIDS  users.  We  concur  in  this  judgment. 

Option  Two  - Use  of  Off-Site  Computer  Facilities 

This  option  would  make  use  of  EDP  resources  (only  those  that  are  compatible  with 
the  B6700)  at  installations  where  computer  time  could  be  purchased  piecemeal.  DLSC  has 
tried  this  option;  in  1976,  some  556  hours  were  used  on  the  State  of  Michigan  Treasury 
Department's  B6700  installation.  We  doubt  that  it  is  feasible  to  transport  sufficient  DIDS 
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work  to  an  off-site  facility  to  affect  the  workload  saturation  on  the  Primary  B6700 
significantly.  As  DLSC  has  noted,  the  logistics  are  complex  and  costly.  Use  of  off-site 
facilities  only  makes  sense  for  emergency  situations  that  require  an  alternate  site  for 
continuance  of  minimal  BIDS  processing.  The  practice  is  infeasible  for  the  alleviation  of 
daily  workload  saturation. 

Option  Three  - Augmentation  of  the  Primary  B6700  with  Larger 

Burroughs  Computers 

For  this  option,  only  Burroughs-compatible  equipment  has  been  considered. 

As  currently  configured,  the  Primary  B6700  has  the  maximum  number  (three)  of 
CPUs,  and  is  about  at  the  maximum  in  memory  modules  and  physical  connections  to  mass 
storage  devices.  Increasing  the  memory  from  the  present  4.7  megabytes  to  the  maximum 
6 megabytes,  or  adding  additional  peripheral  storage  would  not  solve  the  processor 
bottleneck  situation. 

As  a means  of  roughly  sizing  the  potential  costs  of  this  option,  we  considered 
reconfiguring  the  DLSC  existing  and  functionally  separate  B6700  computer  systems  into 
an  integrated  system  via  a Burroughs  Global  Memory  with  a B6800  single  CPU  computer. 
In  this  integrated  configuration,  all  six  CPUs  (three  on  the  Primary  B6700,  two  on  the 
Secondary  B6700,  and  one  on  the  B6800)  can  have  access  to  the  TIR.  For  the  smallest 
B6800  processing  system  (the  B6807)  with  the  minimum  Global  Memory  (~1.5  MB),  and 
retaining  both  B6700  systems,  this  augmentation  is  estimated  to  cost  $1,104,000 
(in  1977  dollars).  If  the  next  larger  B6800  system  (the  B6811)  and  the  maximum  Global 
Memory  (~  3 MB)  are  used  the  augmentation  is  estimated  to  cost  $1,768,000  (in  1977 
dollars).  These  augmentations  would  provide  between  two  to  four  times  the  capacity  of 
the  current  DLSC  BIDS  workload  processing  potential.  Further,  they  are  no  more  costly 
and  an  order  of  magnitude  more  effective  than  the  augmentation  of  the  Secondary  B6700 
proposed  by  DLSC.  Both  of  these  augmentations  maintain  full  compatibility  with  the 
existing  systems  for  minimal  conversion  and  implementation  costs  and  time,  and 
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incorporate  the  potential  for  additional,  substantial  growth.  For  either  of  these 
configurations,  a 16-month  lead  time  from  order  to  installation  is  estimated. 

This  option  does  not  offer  short-term  (3  to  6 months)  relief  for  the  Primary  B6700 
processor  saturation  problem.  If  the  long-term  prospects  for  the  DIDS  workload  exceed 
the  current  projections  and/or  call  for  continued  growth  throughout  the  1980-1990  period, 
then  this  option  or  its  cost-effective  equivalent  will  be  required. 

Option  Four  - Augmentation  of  the  Secondary  B6700  as  Proposed  and 

Oifloading  Work  from  the  Primary  B6700 

This  option  reflects  the  pending  DLSC  proposal.  Based  on  an  unsolicited  proposal 
from  the  Burroughs  Corporation,  the  estimated  cost  for  additional  equipment  (hardware)  is 
$1,628,547  (in  1977  dollars),  with  an  additional  $56,710  for  maintenance,  installation  and 
shipping  costs.^ 

This  augmentation  would  leave  the  Primary  B6700  in  essentially  its  current 
configuration  and  almost  double  the  size  of  the  Secondary  B6700.  A comparison  between 
the  current  and  proposed  augmentation  of  the  Secondary  B6700  is  given  in  Table  S-3. 

TABLE  S-3.  COMPARISON  BETWEEN  THE  CURRENT  AND  PROPOSED 
AUGMENTATION  OF  SECONDARY  B6700  HARDWARE 


Current 

Configuration 

Proposed  Configuration 
After  Augmentation 

Approximate 

Impact 

2 CPUs 

2 CPUs 

No  Change 

100  Megabytes 
of  HPT  Disk 
Storage 

200  Megabytes  of  HPT  Disk 
Storage 

Double  Capacity 

~1  Megabyte  of 
Core  (Memory) 

~ 2 Megabytes  of  Core  (Memory) 

Double  Capacity 

8 Disk  Packs 

21  Disk  Packs 

2i-Fold  Increase  in 
Capacity 

10  1600  BPI 
Tape  Drives 

22  1600  BPI  Tape  Drives 

Double  Capacity 

— 

1 CRT  TD830  Display/Adapter 

L ■ 

New 

3 

DSAH-LS,  Funding  Requirement  for  DLSC  ADD  B6700  Equipment  Augmentation 
Request,  November  18,  1976. 
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How  much  would  the  proposed  augmentation  of  the  Secondary  B6700  relieve  the 
CPU  congestion  on  the  Primary  B6700?  Two  different  efforts  were  made  to  estimate  the 
likely  workload  volume  that  could  be  transferred  from  the  current  and  projected 
Primary  B6700  workload  to  the  Secondary  B6700.  (See  Chapter  IL)  Both  efforts  yielded 
estimates  of  about  85  hours  of  processor  time  per  month  as  the  likely  workload  that  could 
be  transferred.  That  85  hours  is  equivalent  to  about  5.8%  to  7%  of  the  current  monthly 
Primary  B6700  processor  time  potentially  available  for  application  programs.  This 
offloading  of  work  would  certainly  contribute  to  the  relief  of  the  Primary  B6700  processor 
bottleneck,  but  could  not  in  itself  solve  the  problem.  Some  other  alternatives  must  be 
pursued,  if  the  BIDS  workload  bottleneck  is  to  be  relieved. 

We  conclude  that  no  amount  of  equipment  augmentation  on  the  Secondary  B6700  will 
be  adequate  by  itself  to  solve  the  congestion  problem  on  the  Primary  B6700. 

Option  Five  - Optimization  and  Limited  Hardware  Changes  to  Increase 

the  Effectiveness  of  Current  Machines 

Given  the  current  BIDS  situation  and  assuming  the  BLSC  BIBS  workload  projections 
of  Becember  1976,  we  feel  that  this  option  is  the  most  effective  in  the  short  term  of  the 
five  considered  and,  even  if  higher  projections  materialize,  is  the  most  logical  first  course 
of  action.  Both  BLSC  and  Burroughs  personnel  agree  that  it  is  feasible. 

The  effectiveness  of  the  current  machines  could  be  increased  by  smoothing  the  BIBS 
workload,  reducing  the  CPU  congestion  in  the  Primary  B6700,  and  offloading  a maximum 
of  work  from  the  Primary  B6700  to  both  the  Secondary  B6700  and  the  IBM  360/65 J.  We 
also  include  limited  hardware  adjustments  in  this  option. 

We  estimate  that  an  additional  10-20%  of  Primary  B6700  CPU  capacity  could  be 
made  available  for  application  programs,  and  at  least  a 20%  additional  CPU  utilization  on 
the  Secondary  B6700.  These  improvements,  plus  a concerted  strategy  to  offload  work  to 
the  Secondary  B6700  and  IBM  360/65J,  will  relieve  the  current  CPU  congestion  on  the 
Primary  B6700.  Basically,  we  expect  that  optimization  of  the  present  machines  will 
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achieve  everything  Option  Four  does,  plus  yield  additional  opportunities  to  increase  the 
Primary  B6700  effectiveness,  and  at  less  cost. 


t 
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We  discuss  20  actions  that  can  be  taken  to  improve  the  EDP  systems  and  their 
management.  The  first  17  actions  are  listed  in  Table  S-4.  That  table  also  summarizes  the 
actions  by  indicating,  in  terms  of  a relative  three  level  subjective  scale,  their  estimated 
impacts  on  the  Primary  B6700  CPU  congestion,  implementation  times,  and  DLSC  resource 

4 

requirements. 

Some  of  these  actions  are  dependent  on  other  actions,  while  others  are  independent 
or  mutually  exclusive.  We  have  tried  to  identify  all  such  relationships.  We  have  also  tried 
to  indicate  those  actions  that  DLSC  either  has  considered  or  is  presently  considering. 

Actions  15  and  16  are  variations  of  the  proposed  DLSC  ADP  Augmentation  Plan.  We 
estimate  that  the  combined  costs  for  the  additional  hardweire  called  for  by  Actions  15  and 
16  are  $350,000  to  $400,000  (in  1977  dollars).  This  contrasts  with  the  estimated 
$1.6  million  for  the  proposed  ADP  augmentation.  (See  Option  Four.) 

Action  15  calls  for  changing  the  Primary  B6700  hardware  by  adding  the  remote 
cathode  ray  tube  (CRT)  display  console  and  removing  the  surplus  100  megabytes  of  Head 
Per  Track  (HPT)  mass  storage.  The  remote  display  console  will  aid  in  scheduling  and  can 
contribute  to  smoothing  the  workload.  We  do  not  include  the  additional  3 dual-drive  disk 
packs  called  for  in  the  ADP  Augmentation  Plan,  because  they  will  not  help  the  CPU 
congestion  problem,  and  the  current  Primary  B6700  configuration's  11  billion  characters  of 
mass  storage  is  adequate. 

Action  16  involves  adding  1 megabyte  of  core  (memory),  100  megabytes  of  HPT  mass 
storage  (from  the  Primary  B6700),  and  the  remote  console  display  device  to  the 
Secondary  B6700.  This  action  would  modify  the  Secondary  B6700  hardware  differently 
than  the  ADP  Augmentation  Proposal.  (See  Option  Four.)  All  the  TIR  data  processing  and 
updating  would  still  have  to  be  done  on  the  Primary  B6700.  Based  on  our  analysis,  only  5.8 
i 

All  those  actions  are  discussed  in  Chapter  III. 
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TABLE  S-4. 
THROUGH 


INCREASE  EFFECTIVENESS  OF  CURRENT  MACHINES 


pfawwiTOiafitTaiMsriiitwgta 


Softwar«  Imorovements 


1.  Identify  the  CauM  of  and  Reduce  the 
Excessive  Volume  of  GEORQE  Calls 

2.  Remove  MC?  Inefficiencies  in.  Processing 
VariaOle  Length  Data  Records' 

3.  Reduce  the  t^riodic  Peaxing  of  Presence- 
Bit  Overhead"* 

4.  Reduce  Excessive  DMS  II  Activity 


AooUcation  Proerim  Imorovements 


5.  Modify  Trigger  File  PoUo«v-Dp  Processing^ 


$.  Modify  the  COBOL  Compiler  to  Handle 
Variahle  Length  Records  More  Efficiently 

7.  Use  ALGOL  For  Selected  DLSC  Appli- 
cation Programs 

3.  Increase  the  Efficiency  of  Programs 
Processing  the  TIR  File"* 

9.  Increase  the  Efficiency  o'  TIR  Accesses 
hy  Af  ARS 

10.  Reduce  the  .Sumb«  of  Future  Update 
Records  Processed"* 


imerovements  in  the  DIDS  Data  Base 


11.  Reduce,  the  Impact  of  Inpuiries  Without 


Increase  the  Efficiency  of  WcrXload  Scheduling 

12.  Implement  t.he  DLSC  Revised  Queuing/ 
Processing  Concept  vitj  a Time 
Dependent  ChecK  Point"* 

13.  Utilize  Automated  Scheduling  for  3S700 
Worldoads"* 

14.  Process  Only  Full  Batches'* 


Hardware  Changes 


Job  Shoo  Schedulir 


7.  Improve  the  Scheduling  of  Joos  on  the 
Secondary  B6700 


JLOL 

Resource 
( Personnel) 
Required 

H = High 
M = Med 
L a Low 


Action 
Approval  Or 
Dependency 
On  Agencies 
Other  Than 
DLSC 


1.  Actions  18-20  dealing  with  Management  Improvements  are  not  listed  oecausc  their  impact  on  the  Pnmarv  B67C0  CPU 
congestion  is  indirect  and  long  term. 

2.  These  rankings  are  relative  to  the  set  of  17  actions  considered  and  are  rased  on  subjective  judgments. 

3.  S * short  term,  I to  3 months;  M * mid  term,  3 to  3 months:  L * long  term,  5 to  12-pIus  months. 

4.  DLSC  has  sim-Ur  ideas  under  consideration  as  part  of  planned  actions  or  future  actions. 

5.  The  negligible  effort  indicated  is  for  new  programs.  For  the  convers.cn  of  old  programs  the  resource  recuirements  would  be 
high  (H). 


to  7%  of  the  Primary  B6700  workload  (in  processor  hours)  could  be  transferred  to  the 
Secondary  B6700,  regardless  of  how  big  it  is  made. 

The  rationale  for  the  augmentation  recommended  by  Action  16  is  as  follows: 

- Currently  the  Secondary  B6700  is  memory-bound.  That  bottleneck  causes  the 
CPUs  to  be  idle  about  50%  of  the  time.  Doubling  the  current  1 megabyte  of  core 
would  allow  for  fuller  utilization  of  the  currently  idle  CPUs. 

- The  Secondary  B6700  now  has  only  one  electronic  unit  (EU)  for  its  100  megabytes 
of  HPT  disk  storage.  The  additional  100  megabytes  of  HPT  would  double  the 
capacity  of  this  mass  storage  medium  and  add  one  more  EU.  The  additional  EU 
wiU  provide  needed  redundancy,  and  the  extra  100  megabytes  will  provide 
additional  useful  storage  space. 

- The  console/display  device  will  enhance  the  ability  to  schedule  the 
Secondary  B6700  workload.  However,  given  the  nature  of  the  work  on  this 
system,  the  real  justification  for  adding  a remote  console  is  that  it  will  provide  a 
useful  test  bed  for  new  scheduling  concepts  intended  for  the  Primary  B6700. 

AU  the  disk  and  tape  mass  storage  devices  are  not  included  for  two  reasons.  One,  all 
the  workload  to  be  transferred  will  fit  on  the  Secondary  B6700  as  currently  configured. 
Two,  the  thrust  of  the  Augmentation  proposal  is  to  have  sufficient  capacity  on  the 
Secondary  B6700  for  almost  all  the  applications  (both  old  and  new)  to  reside  concurrently 
in  the  system.  Since  most  of  the  new  workload  to  be  transferred  is  to  be  processed  on  an 
"as  required"  basis,  it  should  be  processable  on  the  current  configuration  with  an  improved 
scheduling  procedure.  More  mounting  and  dismounting  of  disks  and  tapes  will  be 
necessary,  but  this  is  a standard  procedure  in  job  shop-type  applications. 

The  last  three  actions  (18,  19  and  20)  deed  with  DIDS  management  improvements. 
They  are  not  listed  in  Table  S-4,  because  their  impact  on  EDP  processing  effectiveness  is 
indirect  and  mid-  to  long-term.  Also,  their  focus  is  different.  Actions  1 through  17  aim 


at  achieving  improved  performance  of  the  Primary  B6700  and  the  Secondary  B6700. 
Actions  18  through  20  focus  on  management  procedures  to  sustain  those  improvements, 
and  to  improve  workload  planning.  The  program  design  reviews  and  quality  assurance 
procedures  would  build  upon  the  existing  DLSC  program  optimization  effort,  and  introduce 
steps  to  ensure  that  the  improvements  called  for  are  in  fact  implemented. 

CONCLUSIONS 

We  recommend  Option  5 as  the  most  cost  effective  short-term  action  to  alleviate 
the  current  and  near-term  BIDS  capacity  limitations.  The  necessary  optimization 
improvements  are  possible  with  the  appropriate  assignment  of  critical  DLSC  resources, 
and  DLA  and  OSD  support. 

If  the  workload  projections  should  be  higher  and/or  reflect  an  increasing  growth 
rate,  then  Option  5 is  still  the  logical  first  course  of  action.  In  that  event,  after  Option  5 
is  taken  and  appropriate  workload  projections  carried  out,  Option  3,  or  its  cost-effective 
equivalent,  should  also  be  pursued. 


XV 


1 


I 
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ARS 

BPI 

CMD 

DMS 

EU 

FIIG 

HPT 

IIM 
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MIX 
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RL 

Segment 


GLOSSARY  OF  TERMS  AND  ABBREVIATIONS 

- Asynchronous  File  Access  Routine  System 

- Alternate  Relocation  Site 

- Bits  per  Inch 

- Catalog  Management  Data 

- Data  Management  System.  Burroughs  Corp.  Software 

- Electronic  Unit 

- Federal  Item  Identification  Guide 

- Head  Per  Track.  Burroughs  Corp.  Mass  Storage  Device 

- Item  Intelligence  Maintenance 

- Identification  List 

- Item  Management  Coding 

- Item  Name  Code 

- Input/Output 

- Interchangeability  and  Substitutability 

- Megabyte  or  1 Million  Bytes  or  Characters 

- Master  Control  Program.  Burroughs  Corp.  Software 

- The  number  of  programs  or  jobs  resident  in  the  computer  at  any  one  time 

- Master  Requirement  Code 

- National  Item  Identification  Number 

- National  Stock  Number 

- Organization  Entity.  A file  in  DIDS  that  indicates  the  assignment  of 
codes  to  manufacturers  and  non-manufacturers 

- Primary  Address  Code 

- Presence-BIT 

- Reference  List 

- A Part  of  a Record.  The  TIR  for  an  item  has  19  segments 
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SoS 


SPARK 

SSR 

STACK 


TIR 

Transaction 


Trigger 
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- Source  of  Supply 

- Systems  Performance  Analysis  Review  Kit.  Burroughs  Corp,  Software 

- System  Support  Record.  A series  of  cross  reference  files 

- An  area  in  memory  in  the  Burroughs  Computer  that  is  assigned  to  a 
program 

- Total  Information  Record.  Currently  about  8 billion  characters 

A unit  of  DIDS  input  workload.  Typically  a single  message  entailing  a 
search,  update  or  inquiry  for  the  TIR 

Temporary  data  in  the  file  to  indicate  when  an  action  or  change  is  to 
become  active  or  effective. 
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BACKGROUND 

The  Defense  Integrated  Data  System  (DIDS)  is  a large-scale,  centralized,  multiproc- 
essor system  that  utilizes  a functionally  integrated,  direct-access  data  base  of  some 
8 billion  characters,  and  processes  about  2.5  million  transactions  monthly.  The  hardware 
and  software  design  and  development  of  DIDS  were  initiated  in  196U.  DiDS  is  designed  to 
provide  data  services  for  logistics  managers  iii  nine  functional  areas:  cataloging,  item 
utilization  and  marketing,  interchangeability  and  substitutability,  supply  management. 
Military  Standard  Item  Characteristics  Coding  Structure  (MILSTICCS\  publications, 
provisioning,  item  entry  control  and  screening,  and  statistics.  Figure  1 shows  the 
interactions  among  these  functions  and  the  DIDS  data  base. 


FIGURE  1.  DEFENSE  INTEGRATED  DATA  SYSTEM  (DIPS') 
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Overall  responsibility  for  BIDS  resides  in  the  Office  of  the  Assistant  Secretary  of 
Defense  (Manpower,  Reserve  Affairs,  and  Logistics),  where  both  policy  and  guidance  are 
developed  and  issued.  Authority  for  the  development  and  implementation  of  BIDS  has 
been  delegated  to  the  Defense  Logistics  Agency,^  which  in  turn  has  made  the  Defense 
Logistics  Services  Center  (DLSC)  responsible  for  the  development  and  design  of  BIDS,  and 
the  development,  coordination  and  maintenance  of  its  operating  procedures.  Close  ties 
with  the  Military  Departments,  General  Services  Administration,  and  Department  of 
Transportation  are  also  maintained. 

Over  the  past  18  months,  attempts  have  been  made  to  improve  BIDS  processing 
capability  by  augmenting  hardware  and  refining  software.  Notwithstanding  these  efforts, 
BIDS  is  still  experiencing  difficulties  meeting  current  workload  requirements,  and  concern 
has  been  growing  over  its  efficiency  and  capacity,  particularly  in  view  of  future 
requirements.  DLSC  has  therefore  submitted  a request  to  augment  BIDS  computer 
equipment  to  alleviate  both  current  and  near-term  capacity  limitations. 

OBJECTIVE 

This  study  was  initiated  at  the  request  of  OASD(MRA&L)  to  provide  useful 
information  for  its  review  of  the  DLSC  ADP  B6700  Equipment  Augmentation  Request. 
Specifically,  LMI  was  tasked  to  carry  out  a BIDS  computer  system  performance  evaluation 
to  assess  whether  the  additional  hardware  requested  would  solve  the  efficiency  and 
capacity  problems,  or  whether  the  present  hardware  could  be  utilized  more  effectively. 

In  order  of  priority,  the  analysis  focused  on: 

- Determining  whether  the  current  hardware  configuration  has  the  capacity  to 
process  the  existing  and  projected  near-term  workload 

- Assessing  the  efficiency  of  the  current  software  (both  for  the  B6700  operating 
systems  and  applications  programs)  and  the  file  design 

^Formerly  the  Defense  Supply  Agency. 
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- Outlining  the  basics  of  an  implementation  plan  to  correct  the  deficiencies  in  the 
hardware  and  software 

- Assessing  the  cost  effectiveness  of  optimizing  the  existing  data  processing 
system  versus  expanding  the  hardware  configuration. 

ASSUMPTIONS  AND  QUALIFICATIONS 

We  did  not  analyze  the  cost  benefits  of  BIDS,  the  workload  demand  or  the  DLSC 
organization;  the  constraints  of  both  time  and  the  task  order  place  them  outside  the  scope 
of  the  study.  By  taking  the  BIDS  workload  as  a given,  we  may  have  overlooked  a fruitful 
area  in  which  to  seek  relief  from  the  current  BIBS  workload  congestion.  Also,  the  task 
order  did  not  call  for  a review  of  all  the  BLSC  on-going  analyses,  programming,  and  BIBS- 
related  activities  (e.g.,  testing  practices). 

Our  conclusions  and  observations  must  be  taken  in  the  context  of  our  treatment  of 
the  BLSC  BIBS  workload  projection  and  BLSC  organization  as  givens.  Their  omission 
from  explicit  consideration  in  this  analysis  does  not  imply  that  they  are  unimportant,  or 
irrelevant  to  the  overall  effectiveness  of  BIBS.  Since  this  study  was  carried  out,  it  has 
been  pointed  out  by  BLSC  that  their  Becember  1976  BIBS  Workload  Projection  was  not 
complete  because  certain  workload  areas  were  not  quantifiable  at  that  time.  A discussion 
of  the  possible  additional  workload  magnitudes  and  its  implication  for  the  study  results  is 
provided  in  Appendix  B. 

METHOBOLOGY 


The  approach  taken  in  this  analysis  consisted  of  the  following  steps: 

Formulation  of  the  Study  Objectives  and  Plan 

The  specific  information  required  by  the  BIBS  review  decision  was  identified,  and 
I the  time  constraints  determined.  From  this  information,  the  focus  and  plan  of  the  study 

f were  decided. 

S-  • 

If 

■ Selection  of  the  Team 

The  analysis  depended  upon  the  availability  of  skills  in  the  following  areas:  EBP 
system  performance  analysis,  B6700  system  architecture,  design  and  evaluation  of 


I 

> 
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large-scale,  direct-access  data  files,  and  MIS  design  and  analysis.  Few  individuals  and 
few  organizations  could  meet  all  these  requirements.  Furthermore,  the  study  plan 
indicated  a short  and  intensive  on-site  visit  requiring  multiple  and  concurrent  interviews. 
A carefully  selected  team  having  appropriate  eclectic  skills  and  experiences  was  therefore 
deemed  necessary.  We  also  expected  the  team  approach  to  enhance  the  quality  of  the 
diagnosis  and  interpretation  of  the  findings. 

Pre-On-Site  Visit  Preparation 

The  success  of  a short  study  of  this  nature  is  heavily  dependent  upon  the  availability 
of  relevant  data.  Our  plan  called  for  the  collection  and  review  of  data,  prior  to  the 
on-site  visit,  that  described: 

- History  and  current  configuration  of  the  BIDS  hardware 

- BIDS  software  and  application  programs 

Current  and  anticipated  BIBS  workload  and  its  content^ 

- BLSC  BIBS  organization  and  resources 

- Availability  and  content  of  past  and  current  BLSC  BIBS  system  and  optimization 
analyses 

- The  key  BLSC  personnel  relevant  to  the  study 

On-Site  Visit  and  Analysis 

The  study  plan  called  for  a short  and  intensive  on-site  visit  to: 

- Interview  key  BLSC  personnel  to  utilize  their  BIBS  experience 

- Review  existing  BIBS  computer  system  monitor  reports 

- Collect  additional  data 

- Execute  special  jobs  on  the  BIBS  computers  to  identify  processing  bottlenecks 

- Assess  the  existing  hardware  capacity 


For  this  analysis  we  utilized  the  latest  BLSC  BIBS  workload  projections  prepared  in 
Becember  1976.  For  a discussion  of  potential  growth  and  workloads  not  included  in  the 
Becember  1976  projection,  see  Appendix  B. 
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- Analyze  the  DLSC  ADP  B6700  Equipment  Augmentation  Request 

- Formulate  options  to  improve  DIDS  effectiveness. 

For  a study  of  this  nature,  an  on-site  visit  is  essential  to  ensure  that  the  actual  conditions 
are  reflected  and  incorporated  in  the  analysis,  and  that  the  analysis  is  relevant  and  the 
recommendations  practicable. 

Interpreting  and  Presenting  the  Study  Findings 

This  last  step  entails  the  synthesis  of  the  different  observations  into  a set  of 
conclusions  directed  at  answering  the  study  objectives,  and  presenting  the  findings. 
OVERVIEW 

The  rest  of  this  report  is  presented  in  two  chapters.  Chapter  II  begins  with  a brief 
account  of  the  current  DIDS,  its  status  and  situation,  which  represents  the  base  case  for 
the  analysis.  Topics  covered  include:  hardware  and  software  configurations;  the  data 
base;  and  the  DIDS  workload,  current  volume,  distribution,  backlogs  and  projections. 
Next,  the  current  capacity  of  the  DIDS  EDP  systems  is  described  and  related  to  projected 
workloads.  Finally,  current  DIDS  limitations  are  analyzed  to  identify  specific  capacity 
limitation  problems  and  their  causes. 

Chapter  III  describes  and  assesses  five  options  for  dealing  with  the  constraints  on 
DIDS  processing  capacity.  One  option.  Increasing  the  Effectiveness  of  Current  Machines 
through  Optimization  and  Limited  Hardware  Changes,  is  selected  as  the  preferred 
alternative,  and  broken  down  into  20  actions  that  would  contribute  to  increased 
effectiveness  of  the  DIDS  EDP  systems. 


5 


II.  DIPS:  CURRENT  CONFIGURATION,  CAPABILITIES.  LIMITATIONS 


DIPS  HARDWARE  CONFIGURATION 

In  order  to  understand  the  study  findings  and  to  place  them  in  perspective,  a 
description  of  the  current  DIPS  EDP  design  and  workload  is  needed.  The  current  system 
constitutes  the  base  case  for  this  analysis.  Because  the  focus  of  this  study  is  very 
specific,  we  have  omitted  any  discussion  of  how  DIPS  steu’ted,  what  the  initial  plan  and 

3 

cost  estimates  were,  and  so  on. 

Currently  the  DIPS  hardware  consists  of  two  Burroughs  B6700s  and  one  IBM  360/65J. 
The  specific  configurations  are  listed  in  Tables  1,  2 and  3.  The  larger  BSTOO*^  is  the 
primary  DIPS  processing  system  and  has  the  maximum  number  (three)  of  central  processor 
units,  and  nearly  the  meiximum  amount  of  memory  modules  and  physical  connections 
installable.  (See  Table  1.) 

The  smaller  B6700^  is  primarily  used  for  program  development  and  testing,  and  the 
processing  of  some  overflow  work  from  the  Primary  B6700.  The  Secondary  B6700  was 
initially  sized  for  testing  requirements  and  is  much  smaller  than  the  Primary  B6700.  (See 
Table  2.) 

Both  B6700's  currently  utilize  the  Master  Control  Program  (MCP)  version  II.7  field 
release  1,  and  the  Data  Management  System  (DMS II)  version  II.7  available  from  the 
Burroughs  Corporation. 

The  IBM  360/65 J (Table  3)  processes  a variety  of  applications  (e.g.,  the  Defense 
Property  Disposal  Service  Integrated  Disposal  Management  System,  Simplified  File 

3 

Some  of  that  information  can  be  found  in  References  2-5. 

“^Hithertofore  this  system  will  be  referred  to  as  the  Primary  B6700. 
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Hithertofore  this  system  will  be  referred  to  as  the  Secondary  B6700. 
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f^BLE  1 

. DLSC 

PRIMARY  B6700  CONFIGURATION 

Model 

Number 

Qty 

Description 

B6724 

1 

Basic  System 

2 

Central  Processirtg  Unit 

1 

Input/Output  Processor 

1 

Console  Display  Terminal 

1 

Optional  PTR/ Keyboard 

1 

Console  Display  Cont-ol 

1 

Adapter  for  Print  Key 

B671S 

1 

Central  Processing  Unit 

B678t 

Input/'Output  Processor 

B673d-1 

IS 

Data  S etching  Cbr^mel 

PBBlK-l 

24 

Memory  lS09  NS,  2,333,296  bytes) 

36l)0S-4 

3 

Memory  ',1.6  L'S,  1,179,348  bytes) 

B6M6-5 

3 

Memory  (1.6  L'S,  1,179,648  bytes) 

B9111 

2 

(Total  - 4,718,592  bytes) 
899  CPM  Card  Reader 

B61ia 

2 

Card  Reader  Control 

B9213 

•% 

tt 

380  CPM  Card  Punch 

B6212 

2 

Card  Punch  Control 

B9243-1 

5 

1190  LPM  Printer 

B6249 

6 

Printer  Control 

39949 

5 

High  Speed  SLEW 

B9941 

3 

.Additional  12  Print  Pos 

B9943 

5 

Printer  .Memory 

M497B 

1 

Macro  OCR  Printer 

B9394-2 

2 

96  KB  Mag  Tape  Unit 

86393-3 

2 

Magnetic  Tape  Control 

36492 

2 

4 X IS  Tape  Exchange 

B9394-1 

4 

7-Channel  Mag  Tape  Unit 

B6391-4 

3 

•MTU  Control 

B9393-3 

34 

9-Channel  Mag  Tape  Unit 

B6393-2 

18 

.MTU  Control 

B6493-2 

3 

2x8  Exchange 

B9375-19 

5 

23  M.S.  Disc  File  (590,906.900  bytes) 

36373 

4 

Disk  File  Control 

B6471 

2 

DF  Exchange 

B9358-41 

1 

Typewriter  Inquiry  Station 

B9339-4 

1 

Optional  Printer  Keyboard 

B6639-1 

1 

Line  Adapter 

B6471-5 

4 

Control  Adapter 

B8471-6 

3 

Electronics  Unit  Adapter 

B948S-4 

18 

Dual  Drive  Disc  Pack 

B948S-4 

43 

Dual  Drive  Increment 

B9974-4 

132 

Disk  Packs 

B6383-2 

9 

Dual  Control 

B9342-1 

2 

Console  Display  Terminal 

B9371-8 

2 

DF  Electronics  Unit 

B9371-2 

1 

Optical  PTR/.Keyboard 

36349 

2 

Console  Display  Control 

36348-1 

3 

Adapter  for  Phnt  Key 

36339 

2 

Deta  Comm.  Processor 

36339-3 

2 

Data  Comm.  Processor  Memory 

39338 

6 

Typewriter  L-.quiry  Station 

36338-1 

2 

Adapter  Cluster 

38659-1 

10 

Line  Adapter 

36799 

1 

Optional  MDL  Processor 

Source: 

DLSC 
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Model 

Number 

B6750 


B6780 

B6005-4 

B6M5-5 

B9111 

B6110 

B9213 

B6212 

B6610 

B9243-1 

B9941 

B6240 

B9940 

B9943 

B9393-3 

B6493-2 

B6393-2 

B9394-1 

B6490 

B6391-4 

B9375-10 

B6373 

B9383-8 

B9486-4 

B6304-1 

B9495-5 

B9499-12 

B6395-7 

B9394-2 

B6393-3 

B6330 

B6350-5 

B6350-1 

B9350 

B6650-1 


Source: 
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TABLE  2.  DLSC  SECONDARY  B6700  CONFIGURATION 


911 


Description 


1 

2 


1 

2 

1 

1 

1 

1 

1 

1 

3 

3 

3 

3 

3 

6 

1 

2 

1 

2 

1 

1 

1 

1 

3 

2 

5 

1 

2 

1 

1 

1 

1 

1 

3 

3 


Basic  System 

CPU's  (5/10  clock),  1 I/O  Processor 
with  12  Data  Switching  Channels,  1 MDL 
Processor,  1 Operator  Console  with  Dual-6340 
Displays,  1 Peripheral  Control  Cabinet  and 
1 Power  Control  Cabinet 
Additional  I/O  Processor  w/12  Data  Switching 
Channels 

Memory  (1.6  US,  786,432  bytes) 

Memory  (1.6  US,  393,216  bytes) 

(Total  - 1,179,648  bytes) 

800  CPM  Reader 

Card  Reader  Control  for  B9111 

300  CPM  Punch 

Card  Punch  Control 

BCL-BCL  Code  Translator  for  B6212 

1100  LPM  Printer,  120  Print  Positions 

Additional  12  Print  Positions  for  B9243-1 

Printer  Control  for  B9243-1 

High  Speed  SLEW  for  B9243-1 

Printer  Memory 

240  KB  MT  Unit  (9-Channel  1600  BPI) 

2x8  Common  Elec.  Exch.  for  B9393-3 
240  KB  Unit  Control 

24-66-96  KC  MT  Unit  (7-Channel  200/5  56/800  BPI) 
2 X 10  Tape  Exchange  for  B9394-1  & 2 
96  KC  Unit  Control 

23  MS  Disk  (100,000,000  bytes,  includes  1 EU 
and  5SU's) 

Disk  File  Control 

Disk  Storage/Dual  Controller-872  MB  (10  Spindles) 
Dual  Drive  Increment  (6  Spindles) 

Disk  Pack  Drive  Control  for  B9383-8 
400  KB  MT  Unit  (9-Channel  160f)  BPI) 

2x8  Master  Elec.  Exch.  for  B9495-6 

400  KB  Unit  Control 

96  KB  MT  Unit  (9-Channel  800  BPI) 

96  KB  Unit  Control 
Data  Comm.  Processor 
24,576  Bytes  of  DCP  Memory 
Adapter  Cluster  for  B6350 
Teletype  Inquiry  Station 
Line  Adapter 


DLSC  j 

J 
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TABLE  3.  IBM  360/65J  CONFIGURATION 


f 


Description 


Type  Model  Quantity 


Central  Processor 
Processor  Storage  (1024K) 

Console  with  operator  control  panel 
Console  Keyboard 
Control  Unit 
Display  Station 
Hardcopy  Printer 
Tape  Control  Unit  with  7-track 
compatibility  and  data  conversion 
feature 

Tape  Control  Unit  capable  of  handling 
1600  BPI  tapes 

Selector  Channel  (two  channels  are 
contained  within  one  physical  unit) 
Drum  Printer  (1250  lines  per  min.) 
Forms  Stacker 

Disk  Controller  (2 -channel  switch  on 
channels  1 and  3) 

Disk  Drive  (312KB  data  rate) 
Multiplexor 

Tape  Drive  (7-track,  200,  556,  and 
800  BPI,  90KB  data  rate  at  800  BPI) 
Tape  Drive  PE/NRZI  (9-track,  800 
and  1600  BPI,  90KB  data  rate  at 
800  BPI) 

Tape  Drive  PE  (9-track,  1600  BPI, 
180KB  data  rate) 

Card  Reader  (1200  cards  per  min.) 
Interpret/Punch  (300  cards  per  min.) 
Tape  Switching  Unit 
Tape  Drive  GCR  (9-track,  6250  BPI, 
780KB  data  rate) 

Tape  Control  Unit  capable  of  handling 
6250  BPI  tapes 


IBM  2065  J 

Ampex  2365 
IBM  2150  1 

IBM  1052  7 

IBM  3272  2 

IBM  3277  2 

IBM  3286  2 

IBM  2803  1 

IBM  2803  2 

IBM  2860  2 

Mohawk  3160  1 

Mohawk  1901 
Potter  5314  1 

Potter  4314  A1 

IBM  2870  1 

Ampex  1624  3 

Ampex  1624  6 

Ampex  1624  6 

IBM  3 5 05  B2 

IBM  3525  P3 

IBM  2816  1 

STC  3650 


STC  3800-IV 


1 

1 

1 

1 

1 

2 

1 

1 


3 

2 


32 

1 

4 

4 


8 

1 

1 

1 

8 

2 


Source:  DLSC 
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Maintenance  and  Publications)  that  are  either  separate  from  the  Primary  B6700  primary 
workload,  or  cannot  be  processed  on  the  B6700's  because  of  capacity  limitations. 


The  IBM  360/65J  is 


currently  undergoing  an  upgrading  of  its  operating  system, 


which,  when  completed,  wiU  give  it  the  latest  field  version  operating  system. 
DIDS  DATA  BASE® 


The  principal  data  source  in  the  DIDS  is  the  Total  Item  Record  (TIR),  which  now 
contains  about  8 billion  characters.  The  TIR  is  organized  hierarchically,  as  shown  in 
Figure  2.  Each  file  or  data  set  shows  the  physical  location  of  other  related  files.  The  part 
of  the  record  that  utilizes  the  National  Item  Identification  Number  (NUN)  is  the  starting 
point  to  access  information  about  an  item.  For  requests  that  do  not  contain  the  NUN,  it  is 
necessary  to  utilize  cross-reference  indices  to  determine  the  NUN. 

The  DIDS  data  base  was  designed  to  combine  within  a single  integrated  file  all  the 
Federal  cataloging  and  management  data  for  stock  numbered  items.  In  addition  to  the 
TIR,  the  DIDS  data  base  contains  a System  Support  Record  (SSR)  File  (about  34  million 
characters),  an  alternate  relocation  site  (ARS)  data  file  (an  extract  of  the  TIR),  and  some 
192  other  master  files  and  1,300  transitory  files.  All  these  data  are  used  to  manage  and 
provide  information  for  about  4.5  million  active  items.  Additionally,  the  file  contains 
1.5  million  inactive  items. 

DIDS  WORKLOAD 

Currently,  only  the  Primary  B6700  has  direct  access  to  the  TIR  file  and  processes  a 
variety  of  functions.  However,  some  non-TIR  Mass  Interrogations,  SSR  File  Maintenance, 
Publications,  Statistics,  and  other  processing  are  done  on  aU  three  systems.  Figure  3 


illustrates  the  different  functions  either  affecting  or  generated  from  the  DIDS  data  base. 


Table  4 lists  the  DIDS  workload  by  functional  requirement  and  indicates  the 
approximate  workload  distribution  across  the  functional  categories.  The  percentages  are 

®See  Reference  7. 
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TABLE  4.  APPItOXIMATE  DISTRIBUTION  OF  DIDS  WORKLOAD  BY  FUNCTIONAL  REQUIREMENT 

AND  COMPTTTER  SYSTEIvTUTILIZATION 
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based  on  average  monthly  machine  utilization  in  v/all  clock  hours,  and  may  not  reflect  the 
distribution  of  the  workload  over  the  data  base  accurately.  The  average  relative  monthly 
machine  utilization  in  waU  clock  hours  by  functional  requirement  is  tabulated  in  Table  5. 


TABLE  5. 


AVERAGE  RELATIVE  MONTHLY  MACHINE  UTILIZATION 


(wall  clock  hours) 


Primary 

Secondary 

DIDS  Functional  Reauirements 

B6700 

36700 

IBM  360 

Total 

Daily  File  Maintenance  (TIR  ic  SSR) 

UM 

237 

237 

CMDN 

70 

70 

O.E.  Cycles 

78 

78 

TOTAL 

331 

385 

Daily  Search  i Ingerrogations 

^arch 

264 

264 

Interrogations 

300 

300 

TOTAL 

564 

Il4 

Trigger  Processing 

CMDN  Triggers 

54 

54 

IIM  Triggers 

22 

22 

TOTAL 

Ts 

Mass  Lnterrcgation/Mass  Changes 

10 

12 

16 

38 

SSR  File  Maintenance 

Cross-Reference  Index  File 

9 

7 

150 

166 

INC  Apolication 

13 

6 

3 

22 

MRD 

.2 

MOE 

5 

5 

TOTAL 

“37 

13 

TIT 

193 

Publications 

DMDN/ML 

8 

5 

55 

68 

IL 

41 

12 

195 

248 

Civil  .Agency  Catalog 

4 

1 

10 

15 

MCRL 

49 

49 

SAMMS  Microfiche 

1 

2 

3 

H4/H8 

3 

11 

14 

H2/H3/H6 

2 

1 

3 

TOTAL 

57 

22 

321 

400 

Statistics 

6 

94 

38 

188 

FUG  Program  Processing 

FUG  Revision  (page  changes) 

49 

23 

72 

PAC  Summary 

68 

13 

36 

Edit  Guide/Sec.  H Pre-edit 

17 

12 

29 

Key  Conputation 

50 

50 

V Segment  Extract 

7 

f 

TOTAL 

m 

32 

244 

Ot.her  DIDS  Processing 

ARS  Processing 

45 

31 

109 

205 

FILDR  File  ?4aintenance 

107 

107 

Simplified  File  Maintenance 

3 

68 

27 

98 

NATO  Output  Consolidation 

16 

1 

7 

24 

.Mail  Sort/Suspense  Processing 

114 

2 

38 

154 

History  Processing 

261 

36 

347 

Trigger  File  Maintenance 

16 

16 

DPDS 

36 

118 

34 

486 

.Air  Force  Support 

6 

28- 

34 

Special  Projects 

41 

id 

9 

60 

Systems  .Management  F'jnctions 

164 

32 

36 

252 

Testing 

46 

213 

145 

409 

Source;  Chart  2 of  Appendix  A of  Reference  2,  and  DLSC  data. 


Note;  These  tabulations  are  in  terms  of  wail  clock  hours  not  processor  hours,  and  reoresent  data  for  the  period 
January-Juiy  1976. 
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The  basic  DIDS  transaction  processes  subrnitted  by  users  (Military  Departments, 
Civil  Agencies,  etc.)  consist  of:  Daily  File  Maintenance,  Daily  Search  and  Interrogations, 
and  Trigger  Processes.  AU  these  transactions  are  currently  processed  only  on  the 
Primary  B6700,  and  consume  about  46.5%  of  its  resources.  While  these  transactions 
constitute  only  about  25%  of  the  total  DIDS  machine  workload,  they  are  very  visible  to 
DIDS  users  and  do  dominate  the  Primary  B6700  workload. 

An  indication  of  the  average  monthly  volume  of  the  DIDS  transaction  processing  for 
interrogations,  searches,  new  item.s.  Item  Intelligence  Maintenance  (IIM),  CMDN,  IIM 
[ triggers,  and  Catalog  Management  Data  (CMD)  triggers  is  provided  in  Table  6.  The 

I average  input  transaction  workload  is  about  2.4  million  per  month  or  78,000  per  day.  In 

[ comparison,  based  on  an  8-day  sample,  the  total  DIDS  input  workload,  which  includes 

I ' mailed  magnetic  tapes  and  cards,  total  Autodin  traffic  (including  the  daily  transactions), 

’ triggers  and  special  projection  is  about  176,000  data  items  per  day.  These  data  are 

' tabulated  in  Table  7.  Thus,  relative  to  the  total  input  workload  in  terms  of  input  data 

I' 

I actions,  the  daily  transactions  account  for  approximately  44%  of  the  total.  However,  as 

i can  be  seen  in  Table  7,  the  input  activity  fluctuates  from  day  to  day. 

I 

' , TABLE  6.  DIDS  TRANSACTION  PROCESSING 


(1  October  1976  through  15  Jammry  1977) 


Interr. 

Search 

New 

Items 

IIM 

CMDN 

ll.M 

TRIGGERS 

CMD 

TRIGGERS 

TOTAL 

Monthly  Average 
Receipts 

KS3,632 

784,373 

22.844 

398,357 

290,640 

68, 157 

202,575 

2.350,967 

Daily  Average 
Receipts 

19.271 

25.899 

754 

13,153 

9,596 

2,263 

6,689 

77.626 

Average  Processing 
Rate  Per  Hour 

3,154 

2.594 

326 

1,747 

3,963 

2,594 

4,836 

2,537 

(106  Days  Experience) 

Daily  Time  Required 
to  process  the  Avg. 
Daily  I/O  at  the 
Avg.  rate  per  hour 

6.11 

9.98 

2.31 

7.53 

2.42 

.37 



1.38 

30.60 

Source:  DLSC  DIDS  workload  data. 


L 


TABLE  7.  DIPS  INPUT  DATA  ITEMS  VOLUME 
(8 -day  data  sample) 


Day 

Mailed 

Magnetic 

Tapes 

Mailed 

Cards 

AUTODIN 

TRIGGERS 

Special 

Projects 

1 

269,000 

9,500 

138,300 

1,800 

19,500 

2 

0 

0 

113,200 

5,900 

23,800 

3 

0 

0 

78,800 

0 

23,100 

4 

2,100 

2,500 

231,900 

3,600 

62,500 

5 

0 

2,700 

165,800 

1,800 

13,300 

6 

0 

7,000 

96,500 

4,000 

18,100 

7 

7,700 

3,700 

99,700 

100 

12,600 

8 

1,000 

5,200 

151,800 

600 

2,900 

107,000 

30,600 

1,076,000 

17,800 

175,800 

Grand 

Total 

= 1,407,200 

Daily  Average 

= 175,900 

Source;  DSLC  DIPS  workload  data 


For  the  current  DIPS  computer  equipment  and  workload  levels,  there  are  various 
levels  of  backlogged  data  items  awaiting  processing  and  additional  functions  scheduled  to 
be  implemented,  as  well.  A general  indication  of  the  status  of  backlogged  items  is  given 
in  Figure  4 and  Table  8,  and  a workload  projection  based  on  machine  wall  clock  hours  in 
Table  9.  A more  thorough  discussion  of  backlogged  items  and  "get  well"  dates  can  be 
found  in  References  2 and  3.  For  the  purposes  of  this  analysis,  it  is  sufficient  to  indicate 
that  there  are  transactions  and  other  data  items  awaiting  processing  and  there  is  a 
projected  increase  in  the  workload.  DIPS  workload  problem  areas  are  summarized  in 
Table  10. 
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FIGURE  4.  APPROXIMATED  DIDS  PROCESSING  BACKLOG* 


1 


*Processing  backlog  Includes: 

• Interrogations  • II  Maintenance 

• Searchs  • CMD/SoS 

• New  Items  • II  Triggers 

• CMD  Triggers 

Note;  nie  processing  backlog,  or  more  accurately  the  number  of  transac- 
tions in  house  to  process,  varies  from  day  to  day.  The  totals 
indicated  reflect  the  amount  of  backlogged  items  at  the  time  of 
the  month  indicated,  and  should  not  be  taken  to  infer  a time  based 
trend. 

Source:  DLSC,  Workload  Plan,  8 February  1977 
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TABLE  8.  INDICATION  OF  DIDS  BACKLOGGED  WORKLOAD 


Functional  Area 

As  of  August  1976 
Estimated  Backlogged 
Workload 

Daily  File  Maintenance 

13,200  to  be  processed 

Daily  Search  & Interrogation 

99,000  to  be  processed 

Trigger  Processing 

None 

Mass  Interrogations  & Changes 

2,000,000  to  be  processed 

SSR  File  Maintenance 

None 

Publications 

None 

FUG  Processing 

9 completed  out  of  53 
scheduled  by  12/77 

Other  DIDS  Processing 

1,870,000  items  to  be  processed 

DPDS 

None 

Special  Projects 

None 

System  Management 

None 

Testing 

None 

Source:  Part  IV  Reference  2. 


The  daily  transactions  are  currently  processed  within  a four-level  priority  structure. 
The  distribution  of  the  daily  transactions  and  the  required  processing  completion  times  are 
tabulated  in  Table  11.  Priority  1 and  2 transactions  collectively  account  for  10  to  12%  of 
the  volume  and  are  the  critical  items  affecting  the  workload  scheduling. 

In  summary,  the  current  system  is  experiencing  workload  backlogs,  and  the  projected 
increases  in  workload  will  clearly  exacerbate  the  current  situation  unless  additional 
processing  capability  is  made  available.  By  the  end  of  1977,  current  DLSC  projections 
prepared  in  December  1976  call  for  a 10%  increase  over  the  current  (1/77)  DIDS  workload, 
based  on  machine  wall  clock  hours. 


TABLE  9.  PROJECTED  WORKLOAD  FOR  DIDS  IN  MACHINE  PRODUCTION  WALL  CLOCK  HOURS 
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Source:  rhnrt  3 of  A()pctu1ix  A of  Reference  2,  hiuI  0151'  DIDS  Worklond  Projections  ns  of  December  I97H 


TABLE  10.  SUMMARY  OF  DIDS  PRIORITY  PROBLEM  AREAS 
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PROBLEM  AREAS 
(By  Priority) 

APPLICATIONS/OPERA  riONS 
(Functional  Requirements)  v. 

ITEM  INTELLIGENCE  (TIH)  MAINTENANCE 

1.  Add,  Delete,  t'liange  II  data 

2.  Add,  Delete,  Change  Cut.  Mgt.  Data 

3.  Add,  Delete,  Change  Freight  Cless.  Data 

4.  Arkl,  Delete,  Change  Item  Status  Data 

5.  Interchangeability  and  Substitutability  (IAS) 

6.  Mass  Change  to  TIR 

SEARCH  AND  INTERROGATION 

7.  Search  for  NSN  by  Part  f and/or  (Tiaracteristic  Data 

8.  Tailored  Interrogation  by  NSN 

9.  Moss  Interrogation  by  Specific  Grouping  Key 

STATISTICAL  REPORTS 

10.  Recurring  External  Reports 

It.  Reports  Generator 

PUBLICAIIONS 

12.  Hook  Type  Catalogs/llandbooks 

IJ.  Federal  Item  l.ogistics  Data  Record  (FILDll) 

14.  Tailored  Narnitive  Item  Identification 

MISCELLANEOUS 

15.  NATO  Interface 

16.  Item  Study  List 

17.  Files  Compatibility 
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Source:  A|>pon<)ix  Ei  of  Reference 


TABLE  11.  DAILY  TRANSACTIONS  WORKLOAD  BY  PRIORITY  CLASS 
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ANALYSIS  OF  CURRENT  DIPS  LIMITATIONS 

r 

The  primary  purpose  of  our  on-site  visit  was  to  determine  the  nature  of  the  capacity 
limitations  that  DIDS  is  experiencing,  and  to  assess  the  need  for  equipment  augmentations  I 

^ to  handle  backlogs  and  prospective  workload  increases. 

The  following  discussion  reflects  the  investigations  and  observations  made  during  the 
on-site  visit  and  analysis,  and  incorporates  written  comments  from  different  members  of 

7 

the  study  team. 

I 

Importance  of  the  Data  Processor 

. One  of  the  first  analyses  performed  was  to  determine  the  amount  of  time  the  data 

processors  (central  processing  units)  were  active  in  performing  the  DIDS  workload.  This 
emphasis  was  chosen  because  of  the  operating  characteristics  of  the  Primary  B6700 
system  and  the  critical  importance  of  the  data  processor  resource  to  workload  throughput. 

7 

Specifically  Dr.  Tom  Bell,  Mr.  Michael  Bealmear  and  Mr.  Bob  November  of 
PMM&Co.  (Reference  1),  Mr.  Bill  Dickson,  a consultant,  and  the  author. 
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Priority  Class 

% of  Daily  Transactions 

1.  To  be  processed  within 
4 hours  or  receipt 

0.2% 

2.  To  be  processed  within 
12  hours  of  receipt 

10-12% 

3.  To  be  processed  within 
48  hours  of  receipt 

10-12% 

4.  To  be  processed  within 
72  hours  of  receipt 

73% 

Other  work  to  be  processed 
on  a time  available  basis 

5-7% 

Source;  DLSC  DIDS  Monthly  (IMS  22)  Statistical  Report. 


We  first  explain  why  one  resource  can  be  the  prime  determinant  of  throughput  and  then 
describe  the  specific  situation  on  the  Primary  B6700  system. 

Workload  Bottlenecks 

A modem  computer  system  includes  various  resources  that  are  in  simultaneous 
use.  For  example,  a B6700  may  include  several  data  processors  (up  to  three),  several  I/O 
processors  (up  to  three),  a number  of  data  channels  (up  to  36),  and  a variety  of  peripheral 
equipment,  including  disks,  tape  drives,  card  punches,  card  readers,  and  so  on.  The 
operating  system  of  such  a computer  tries  to  employ  the  individual  resources  so  that 
several  jobs  concurrently  advance  toward  completion.  Each  job  may  simultaneously  use 
several  resources  (e.g.,  two  disks,  a pair  of  channels,  an  I/O  processor,  and  a data 
processor),  but  only  a few  resources  (primarily  memory)  may  be  used  by  more  than  one  job 
during  a particular  instant  of  time.  If  all  the  jobs  made  heavy  demands  on  one  resource  in 
relatively  scarce  supply,  they  will  tend  to  be  awaiting  the  availability  of  that  resource 
much  of  the  time. 

In  a "balanced"  computer  system,  jobs  tend  to  wait  on  the  availability  of 
several  resources  at  different  times.  No  one  resource  is  predominant  in  limiting  the 
production  of  the  system.  On  the  other  hand,  jobs  running  on  a computer  with  a "limiting" 
or  "bottlenecked"  resource  have  to  wait  for  that  resource,  because  it  is  in  use  nearly  all 
the  time.  Meanwhile,  other  resources  may  be  used  very  little.  A single  resource  will 
almost  never  be  in  use  100%  of  the  time,  however,  because  all  the  jobs  will  occasionally 
need  to  use  some  other  resource.  Therefore,  a resource  with  a very  high,  but  not  100%, 
utilization  is  probably  a bottleneck.  The  additional  indication  of  such  a bottleneck  is  the 
very  low  utilization  of  other  resources. 

In  a "balanced"  computer,  the  effects  of  removal  or  addition  of  a certain 
amount  of  resource  is  difficult  to  determine,  because  of  the  complexity  of  all  the  possible 
interactions  among  other  jobs  and  resources.  If  the  computer  is  bottlenecked  on  a single 


resource  however,  the  effects  are  reasonably  easy  to  determine,  because  performance  is 
essentially  linearly  related  to  the  amount  of  the  resource  added  or  deleted. 
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DIPS  Primary  B6700  Processor  Utilization 

Our  initial  impression,  based  on  reports  from  the  SUMLOG  file,  was  that  the 
data  processors  at  DSLC  were  not  heavily  utilized.  (SUMLOG  is  the  machine  usage 
reporting  file  produced  by  MCP,  the  Burroughs  Master  Control  Program.)  The  reports  for 
recent  weekly  activity  indicated  utilization  that  varied  between  32%  and  55%.  This  level 
of  utilization  indicates  that  the  processors  are  not  bottlenecked,  but  in  fact  less  active 
than  they  should  be,  due  to  some  other  limiting  resource. 

The  impression  of  under-utilization  proved  to  be  incorrect.  We  assumed  that 
overhead  (which  would  not  be  reported  in  SUMLOG)  was  no  more  than  10%  and  that  all  the 
processor  time  consumed  was  reported.  Both  assumptions  turned  out  to  be  untrue. 

We  employed  software  tools  written  by  Burroughs  to  determine  the  extent  of 
processor  utilization  and  to  evaluate  our  initial  assumptions.  These  tools  were  parts  of 
Burroughs'  SPARK  (System  Performance  Analysis  Review  Kit)  and  included  SAMPLER, 
SAMPLEANALYZER,  and  LOGSTATISTICS.  SAMPLER  examines  the  computer's 
performance  data  about  every  5 seconds  and  outputs  the  data  for  subsequent  analysis  by 
SAMPLEANALYZER.  LOGSTATISTICS,  on  the  other  hand,  uses  the  data  directly  from 
the  SUMLOG  file  and  produces  reports  much  like  the  ones  regularly  produced  at  DSLC. 
The  advantage  of  LOGSTATISTICS  over  the  DSLC  programs  is  its  indication  of  the  amount 
of  data  in  SUMLOG  excluded  from  the  reports  of  total  processor  utilization. 

We  found,  with  SAMPLER,  that  processor  utilization  on  the  Primary  B6700  is 
about  95%  during  most  periods  of  operation.  MCP  overhead  and  other  unreported  time 
made  up  approximately  25%  to  40%  of  the  total  processor  time.  This  time  is  larger  than 
would  normally  be  expected  and  is  covered  in  the  discussion  below  on  overhead  analysis. 
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Finally,  we  discovered  that  other  resources  (disks,  packs,  channels,  I/O  processors,  etc.), 
were  not  heavily  used.  If  we  believe  SAMPLER  and  disregard  the  DSLC-produced  reports, 
the  processor  is  the  limiting  resource. 


With  LOGSTATISTICS,  we  found  that  much  of  the  data  in  the  SUMLOG  file  is 
not  processed  in  the  regular  way.  One  record  out  of  a pair  is  lost  in  reporting  the  activity 
of  each  job.  We  did  not  determine  the  precise  cause  of  this  "dropping"  of  records,  but  we 
did  observe  that  it  is  most  prevalent  for  long-running  jobs.  Such  jobs  typically  consume 
great  amounts  of  processor  time,  and  the  failure  to  report  their  consumption  grossly 
distorted  the  reported  processor  utilization  in  DSLC  and  LOGSTATISTICS  summaries. 

We  concluded  that  the  utilization  reported  by  SAMPLEANALYZER  reflects 
the  actual  situation,  and  that,  because  of  dropped  records  and  high  overhead,  the  low 
processor  utilization  reported  from  SUMLOG  is  incorrect.  Therefore,  the  Primary  B6700 
is  actually  processor-bound;  its  performance  is  determined  almost  solely  by  the  allocation 
of  this  resource.  Accordingly,  projections  of  its  performance  must  be  based  on  an  analysis 
of  its  processor  activity. 

Primary  B6700  - Overhead  Analysis 

In  the  process  of  making  SPARKANALYZER  runs  against  several  SAMPLER  tapes 
from  the  Primary  B6700  system,  it  was  noted  that  approximately  25%  to  40%  of  the  total 
available  central  processor  time  was  devoted  to  non-user  overhead  (i.e.,  MCP,  DMS  II,  and 
related  activities).  At  the  average  this  overhead,  taken  as  an  aggregate  number,  implies 
that  one  out  of  the  three  processors  on  the  Primary  B6700  system  is  unavailable  for 
processing  application  programs.  The  SAMPLER  tapes  used  in  this  analysis  were  created 
at  various  intervals  during  normal  processing  periods,  with  the  sampling  duration  ranging 
from  2 to  10  hours.  While  system  overhead  rates  in  the  20%  range  are  more  typically 
experienced  on  other  Burroughs  configurations,  the  25%  to  40%  overhead  appears  to  be 
typical  for  the  Primary  B6700. 
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This  overhead  rate  appears  to  be  comprised  of  the  following  elements: 

- High  activity  in  the  GEORGE  procedures  of  MCP® 

- Periodic  peaking  of  Presence-Bit  overhead 

- Indirect  overhead  of  DMS  II,  and 

- Other. 

Each  point  is  briefly  discussed  below. 


GEORGE  Activity 

We  found  that  the  "Calls/Second"  recap  on  the  Processor  Time  Summary  report 
from  SPARK  was  consistently  high.  The  total  calls/second  typically  were  in  the 
400  to  500  range.  This  is  equal  to  a call  being  handled  every  2 milliseconds.  For  certain 
telecommunications  applications  in  which  the  MCP  monitors  every  EVENT  switch  such  a 
number  of  calls/second  is  not  abnormal,  however  for  the  BIDS  application,  a rate  of 
100  calls/second  would  be  expected.  Generally  80%  to  90%  of  these  calls  were  in  the 
GEORGE  category.  We  have  learned  from  Mr.  Jim  Omah  of  the  Burroughs  Corporation 
that  calls  to  the  GEORGE  Procedures  of  the  MCP  are  typically  to  field  I/O  interrupts 
from  the  multiplexors  and  DCPS,  or  to  effect  synchronization  between  processors  or 
application  tasks. 

We  concluded  from  analysis  of  the  I/O  Summary  and  Datacom  Summary 
Reports  that  the  high  GEORGE  activity  was  not  directly  attributable  to  I/O  rates.  There 
is  currently  no  way  of  tracking  processor  to  task  synchronization  from  existing  SPARK 
reports.  Modifications  to  the  MCP  Eire  required  to  retrieve  the  data  to  determine  what  is 
invoking  the  GEORGE  calls. 

Presence-Bit  Activity 

Although  the  average  processor  utilization  devoted  to  Presence-Bit  (P-BIT) 
overhead  is  not  excessively  high,  we  noted  from  processor  time  series  analysis  that  P-BIT 


Q 

GEORGE  is  the  Burroughs  Corporation  designation  for  one  of  the  Master  Control 
Program  (MCP)  executive  routines. 
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activity  peaked  periodically  at  as  high  as  80%  of  the  processor  utilization,  P-BIT  peaking 
suggests  that  a "leveling"  of  processor  mix  could  prevent  a "thrashing"  mode  of  operation. 
This  leveling  could  be  achieved  by  reviewing  the  operations  job  schedule  and  then  ensuring 
that  schedules  and  priorities  not  be  overridden  by  computer  operators. 

Data  Management  System  (DMS  11)  Activity 

Because  DMS  II  does  not  appear  as  an  application  task  on  any  SPARK  reports, 
it  is  not  possible  to  quantify  DMS  II  overhead  from  SPARK  data.  The  situation  is 
complicated  by  the  fact  that  any  DMS  li  tssK  management  associated  with  an  application 
stack  is  captured  in  the  processor  time  charged  to  that  application,  while  activities  such 
as  I/O  and  traffic  management  are  not  captured  and  reported  at  all.  This  problem  is 
further  illustrated  by  the  fact  that  on  every  Processor  Summary  Report  examined,  only 
84%  of  all  available  processor  time  could  be  accounted  for,  including  idle  time.  The 
remaining  time  simply  does  not  appear  on  the  SPARK  reports.  Although  not  all  of  the 
16%  differential  is  attributable  to  DMS  II,  we  certainly  suspect  that  a significant  portion 
of  it  is.  (The  balance  of  the  unlogged  time  is  probably  due  to  random  occurrences  in  MCP, 
errors  in  the  sampling  software,  and  to  other  unknown  effects.) 

Other  Activity 

Other  observations  indicate  inefficiencies  in  the  processing  of  variable  length 
data  records  on  the  Primary  B6700,  and  the  occurrence  of  "move  spaces"  pattern  on  the 
panel  lights  of  the  Primary  B6700  system.  Both  of  these  conditions  have  been  known  to 
DLSC-D  personnel  for  some  time.  Despite  previous  optimization  efforts,  the  problems 
continue  to  exist. 

Estimation  of  Workload  Transferable  from  the  Primary  B6700 
to  the  Secondary  B6700 

The  transfer  of  workload  currently  on,  or  planned  for,  the  Primary  B6700  to  the 
augmented  Secondary  B6700  is  a central  consideration  in  the  DLSC  plan  to  increase  DIDS 
processing  capacity.  In  the  DLSC  request  for  B6700  equipment  augmentation  submitted  in 
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November  1976,  the  workload  in  current  production  (wall  clock)  hours  that  could  be  moved 
from  the  Primary  B6700  to  the  Secondary  B6700  was  estimated  at  475  (wall  clock)  hours 
per  month.  In  December  1976,  DLSC  revised  their  estimate  to  636-799  (wall  clock) 
production  hours  per  month. 

Because  the  issue  of  workload  transferability  was  central  to  this  study,  we  employed 
two  different  approaches  and  two  different  groups  of  analysts  to  make  two  independent 
estimates.  We  also  wanted  an  independent  check  on  the  DLSC  estimates  and  projections 
based  on  wall  clock  hours,  since  wall  clock  hours  are  an  inaccurate  representation  of  the 
"net"  processor  resource  requirements  in  a multiprogram  and  multiprocessor  environment. 

Estimate  A 

This  approach  started  with  estimates  of  the  jobs  DLSC  personnel  had  identified 
that  could  be  transferred.  We  first  identified  the  program  workload  that  is  functionally 
separable  from  the  Primary  B6700  and  especially  the  TIR  data  base.  Secondly,  we  utilized 
the  "Monthly  Summary  of  Job  Elapsed  Processing  Requirement  Reports"  for 
November  1976  and  December  1976.  This  gave  us  a 2-month  sample  of:  elapsed  (wall 
clock  or  production)  time,  processor,  and  I/O  time  by  application  program.  Thirdly,  with 
DLSC  assistance,  we  estimated  the  most  likely  percentage  of  the  program  workload 
(identified  in  Step  1 of  our  effort)  that  could  be  transferred  confidently. 

With  these  data,  we  estimated  the  amount  of  "net"  workload  in  processor  hours 
that  could  be  transferred  from  the  Primary  B6700  to  the  Secondary  B6700.  These 
computations  are  tabulated  in  Table  12.  The  results  of  this  computation  indicate  that 
about  85  processor  hours  per  month  can  be  transferred.  If  we  assume  that  all  the 
appropriate  application  programs  could  be  transferred,  which  is  not  practicable,  the 
estimate  is  about  121  processor  hours  per  month. 

For  a 30-day  month,  the  Primary  B6700  system  with  three  processors  has 
potentially  2,160  processing  hours  available.  Adjusting  for  the  current  preventative 
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TABLE  12.  ESTIMATE  OF  APPLICATION  PROGRAM  WORKLOAD 
TRAiJSFERABLE  FROM  THE  PRIMARY  B6700 
TO  THE  SECONDARY  B6700 
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maintenance  schedule  (about  185  hours  per  month  for  the  three  processors),  and  assuming 
very  idealistically  no  unscheduled  maintenance  (which  currently  exceeds  the  preventative 
maintenance  time),  leaves  about  1,975  hours  per  month.  Depending  upon  the  actual 
overhead  rate  on  the  Primary  B6700,  the  85  hours  of  workload  to  be  transferred  to  the 
organization  Secondary  B6700  would  amount  to  about  5.8%  (for  a 25%  overhead  rate)  or 
about  7.2%  (for  a 40%  overhead  rate)  of  the  processing  capacity  of  the  Primary  system. 
This  5.8%  to  7.2%  reduction  is  based  on  empirical  data,  but  also  assumes  that  DLSC 
personnel  have  identified  all  the  appropriate  jobs  for  offloading. 

Estimate  B 

The  data  for  this  analysis  were  obtained  by  the  SPARK/LOGSTATISTICS 
Program  over  the  period  of  February  2,  1977,  through  February  9,  1977  (196  continuous 
hours).  Data  were  obtained  from  the  "Total  Processor  Time"  and  "Exception"  reports  of 
the  program  product.  The  "Total  Processor  Time  Report"  contains  a summary  of  the 
various  elements  of  the  application  programs,  including  processor  time  usage.  The 
"Exception  Report"  only  includes  those  executions  which  the  analyzer  identifies  as 
starting  and  ending  in  the  sample  time  period.  We  have  called  these  executions  "matched" 
data.  The  "Exception  Report"  also  includes  detailed  data  on  programs  that  the  analyzer 
could  not  identify  as  starting,  but  that  could  produce  facility  usage  data.  We  have  called 
these  executions  "unmatched  data."  Finally,  the  "Exception  Report"  identifies,  but  does 
not  summarize,  tasks  running  but  terminated  by  HALT/LOAD.  These  are  not  included  in 
the  summary  analysis. 

Source  of  Application  Programs  Subject  to  Transfer  - Various  application 
programs  were  identified  as  wholly  or  partially  transferable  from  the  Primary  B6700  to 
the  Secondary  B6700  system.  These  applications  included  those  that  did  not  access  the 
TIR  data  base  at  all  and/or  those  that  did  not  substantially  access  the  TIR.  Among  the 
non-transferable  applications  that  did  not  access  the  TIR  were  such  applications  as  Input 
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[ and  Output  Control,  which  is  an  integral  part  of  transaction  processing.  The  list  of 

i I 

f * transferable  application  programs  was  taken  from  the  Program  Functional  Flow  Charts  (or 

I/O  charts)  and  conversations  with  DLSC  personnel.  Given  the  time  constraints,  we  were 
not  able  to  identify  the  appropriate  category  for  some  applications.  They  were  considered 
separately  (unknown)  and,  assuming  the  best  possible  case,  completely  transferable  to  the 
Secondary  B6700. 

' Computation  Methodology  for  Program  Transfers  - The  following  procedure 

was  used  to  compute  the  processor  time  of  the  Primary  B6700  workload  that  could  be 
moved  to  the  Secondary  B6700. 

Produce  Summary  of  Matched  and  Unmatched  Processor  Time  Data  - 
Applications  (or  shares)  subject  to  transfer  (TRANSFER) 

Applications  (or  shares)  not  subject  to  transfer  (NOT  TRANSFER) 

- Applications  that  could  not  be  readily  identified  as  either  TRANSFER  or 
NOT  TRANSFER  (UNKNOWN) 

- SPARK  applications  (ANALYSIS)^ 

Combine  Data  For  Calculations  - 

- Combine  matched  and  unmatched  data 

- Determine  total  application  processor  time  (without  ANALYSIS) 
(TRANSFER  + NOT  TRANSFER  + UNKNOWN) 

Compute  - 

Monthly  time  saved  from  TRANSFERS. 

TIME  = TRANSFERS  x (30/7). 

(30/7  factors  the  weekly  time  up  to  a full  month.) 

Monthly  time  saved  by  TRANSFERS  and  UNKNOWN. 

TIME  = (TRANSFERS  + UNKNOWNS)  x (30/7). 

9 

The  processor's  time  consumed  in  SPARK  applications  was  excluded  from  the 
analysis  because  this  time  was  consumed  only  to  support  our  analysis;  it  is  not  regular 
work. 


31 


I 


Computation  Methodology-  fof  Application  Utilization  - The  following 
procedure  was  used  to  compute  the  processor  time  utilization  on  the  Primary  B6700: 

Determine  Processor  Time  Used  - 

- All  applications  except  ANALYSIS. 

TOTAL  TIME  = TRANSFERS  + UNKNOWN  + NOT  TRANSFERS. 

- All  applications  except  ANALYSIS  and  transferable  applications. 

TOTAL  TIME  = NOT  TRANSFERS. 

Determine  Total  Processing  Time  Available  - 

- TIME  AVAIL  = (total  time  in  time  period  less  preventative  maintenance) 

X number  of  processors  (3). 

Computations  - Table  13  contains  the  summary  of  MATCHED  and 
UNMATCHED  times.  Table  14  summarizes  the  calculations  below: 

Application  Transfers  to  the  Secondary  B6700: 

Monthly  Time  Saved  on  Primary  B6700  for  TRANSFERS  only  = 

TIME  = 70,897.408  x (30/7)  = 303,846.02  seconds  = 

84.4  Processor  Hours. 

Monthly  Time  Saved  on  Primary  B6700  for  TRANSFERS  and 
UNKNOWNS  = 

TIME  = 88,591.748  x (30/7)  = 379,678.91  seconds  = 

105.5  Processor  Hours. 

Secondary  B6700  Capacity  Analysis 

A SPARK  analysis  similar  to  that  performed  on  the  Primary  B6700  was  carried  out 
for  the  Secondary  B6700.  Two  observations  were  made  almost  immediately.  One,  all  but 
approximately  3%  of  the  total  available  processor  time  could  be  accounted  for,  a marked 
contrast  with  the  16%  figure  on  the  larger  system.  This  variance  can  be  interpreted  as 
the  difference  in  mix  and  type  of  applications  run  on  the  two  systems.  For  example, 
DMS  II  runs  almost  continuously  on  the  Primary  B6700  system,  but  is  used  only  during 
testing  on  the  Secondary  B6700. 
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TABLE  13.  TIME  SUMMARY  FROM  LOGSTATISTICS 
(Processor  Seconds) 


Data 

Matched 

Unmatched 

Combined 

A.  Not  Transfers^ 

602,447.15 

52,408.232 

654,855.382 

B.  Transfers^ 

67,858.3 

3,039.108 

70,897.408 

C.  Unknown 

17,262.0 

432.34 

17,694.34 

D.  Analysis 

35,740.0 

0.00 

35,740.00 

E.  Total  Application 
Time 
(A+B+C) 

743,447.12 

F.  Total  Transfer 
Time 
(B+C) 

88,591.748 

Application  Tasks  (Total): 

16,155 

Application  HAbT/LOAD: 

524 

^Transfer/not  transfer  reflect  applications  that  are  both  totally  and  partially 
transferable. 


TABLE  14.  TRANSFER.ABILITY  SUMMARY 


Processor  Time  of  Transferable  Programs 

Transfers  only  84.4  hours 

Transfers  and  unknown  combined  105.5  hours 


Second,  the  relative  percentage  of  GEORGE  activity  on  the  Secondary  B6700  Js 
considerably  less  than  on  the  Primary  B6700.  This  is  partly  attributable  to  the  fact  that 
the  idle  time  on  the  Secondary  B6700  processors  approaches  50%.  Similarly,  an  average 
mix  factor  of  32  was  observed  on  the  larger  system,  while  the  average  mix  on  the 
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Secondary  B6700  rarely  exceeded  12.  This  disparity  is  too  large  to  be  explained  by  the 
I 

difference  between  a 3-processor  and  a 2-processor  system,  given  enough  work  to  overload 
each  system  at  any  time. 

This  second  observation  prompted  us  to  examine  the  processor  and  core  utilization 
time  series  reports.  The  analysis  led  to  our  major  conclusion  regarding  the 
Secondary  B6700  system.  That  is,  while  memory  is  being  used  to  its  fullest  extent,  there 
is  often  50%  processor  idle  time  on  the  system,  which  implies  that  on  the  average  one  of 
the  two  processors  is  idle  during  production. 

In  analyzing  the  peripheral  units  utilization  reports,  we  observed  no  heavv  demand 

i 

on  either  tape  or  disk  units.  This  could  be  attributed  to  the  lack  of  memory  constraint, 
^ but  is  difficult  to  determine  at  this  point  in  time.  However,  there  is  no  evidence  of  anv 

form  of  I/O  contention  on  the  system  during  production. 

Application  Program  Analysis 

Processing  TIR  records  for  application  consumes  more  of  the  computer's  resources 
than  any  other  DIDS  activity.  We  examined  the  application  programs  LDIM3500  and 
LDEC3500,  which  update  the  TIR.  These  programs  process  large  volumes  of  data  and 

I 

require  extensive  EDP  resources.  Discussed  below  are  three  broad  categories  where 
processing  improvements  are  possible:  AFARS  Interface,  Trigger  File  Processing,  and 

Optimizing  Application  Programs. 

• I 

Asynchronous  File  Accessing  Routine  System  (AFARS)  Interface 
Considerable  processing  is  required  for  the  application  programs  to  access  the 
TIR.  This  is  accomplished  through  the  AFARS  programs  (LBEN6900  and  LBEN9900). 
Greater  efficiency  in  the  interface  process  could  be  achieved  by: 

- Changing  the  processing  technique,  using  CAUSE,  WAIT,  and  RESET 

' 
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- Building  an  entire  TIR  entry  with  one  access  to  AFARS 

- Reducing  the  number  of  TBZR  segments  used.^^ 

The  CAUSE  statement,  followed  by  WAIT  and  RESET,  was  designed  for 
asynchronous  processing.  A CAUSE  is  issued  to  initiate  processing  in  the  caused  program 
while  the  causing  program  continues  its  processing.  When  the  causing  program  is  ready 
for  the  caused  program's  results,  it  then  issues  a WAIT,  RESET.  In  the  applications 
examined,  the  CAUSE  is  immediately  followed  by  the  WAIT  and  RESET  statements. 
Hence,  no  asynchronous  processing  is  accomplished. 

The  retrieval  of  an  entire  TIR  entry  is  now  accomplished  one  segment  at  a 
time,  and  one  subsegment  at  a time  for  multiple-sectioned  segments.  The  update 
program,  for  example,  requires  all  segments  for  editing.  Each  such  retrieval  is  a separate 
ii./ocation  of  AFARS.  Similarly,  when  updating  or  record  creation  takes  place,  each 
segment  to  be  updated  or  created  must  be  passed  to  AFARS  separately.  The  process  could 
be  improved  by  allowing  the  program  to  access  AFARS  only  to  retrieve  or  update  an 
entire  TIR  entry.  For  those  searches  and  inquiries  in  which  only  one  segment  is  required, 
the  current  procedure  is  effective. 

Trigger  File  Processing 

Trigger  transactions  are  created  for  each  future  update.  They  have  two 
purposes:  One,  to  change  a future  update  to  a current  (i.e.,  permanent)  update,  and  two, 
to  initiate  the  notification  required  when  this  change  is  made.  These  are  high  volume 
transactions  that  currently  must  be  processed  near  the  15th  and  end  of  each  month.  This 
requirement  seriously  affects  the  normal  transaction  processing. 

One  way  to  modify  trigger  processing  would  be  to  handle  the  notification 
portion  of  the  process  completely  outside  of  the  TIR.  At  present,  notification  is  done  both 

^ These  are  data  fields  used  to  store  information  on  future  users  of  the  item.  The 
DLSC  Maintenance  Management  Release  (MMR)  8 (D1D360)  action  includes  the 
requirement  to  reduce  the  number  of  TBZR  segments  used. 
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when  the  future  update  is  made  and  on  the  effective  date  as  well.  If  the  initial 
I notification  were  saved  and  reissued  on  the  effective  date  (e.g.,  from  a tape  file),  the 

second  notification  could  be  accomplished  off-line.  A further  modification  would  be  to 
eliminate  effective  date  notification  altogether,  since  the  DIDS  users  to  be  notified  have 
already  been  notified  during  the  initial  update  processing.  j 

The  change  from  future  to  current  updating  could  be  handled  as  a part  of  daily  i 

processing  rather  than  as  a separate  operation.  For  example,  the  next  time  that  a TIR  i 

record  is  updated,  it  could  first  be  checked  for  future  updates  on  past  dates.  If  such 
updates  have  been  made,  the  change  could  be  effected  immediately.  Some  additional 
daily  processing  and  perhaps  a larger  future  file  would  be  required,  but  a portion  of  the 
large  volume  of  trigger  transactions  and  their  bi-monthly  processing  would  be  eliminated. 

Optimization  of  Application  Programs 

Numerous  application  program  optimizations  could  be  implemented.  DLSC 
applications  programmers  are  aware  of  and  have  documented  many  of  them,  including 
those  noted  below.  We  understand  that  many  of  the  recommended  optimizations  have  not 
been  implemented.  Inefficient  processing  of  variable  length  records  and  utilization  of 
work  areas  are  significant  problems.  Several  possible  solutions  are; 

Use  only  variable  length  records  when  a fixed  length  record  is  not 
warranted. 

Call  on  ALGOL  programs  to  accomplish  the  MOVE  to  the  areas  in  question. 

Modify  the  COBOL  compiler  to  handle  variable  length  records  properly. 

- Change  the  working  storage  area  to  ensure  that  the  MOVES  are  fixed. 

Instead  of  COBOL,  ALGOL  could  be  used  as  the  application  programming 
language  for  selected  programs.  The  B6700  architecture  designed  is  based  on  the 
ALGOL  logic  structure,  and  ALGOL-coded  programs  will  run  more  efficiently  than 
COBOL  programs  on  these  computers. 

Improved  use  of  working  storage  areas  could  reduce  the  core  requirements  of 
the  application  programs.  An  example,  already  under  consideration  at  DLSC,  is  to  use 


36 


different  versions  of  the  update  programs  to  process  different  length  records.  Working 
I 

storage  can  be  reorganized  to  make  better  use  of  core  memory.  For  example,  many 
77  and  01  levels  in  memory  require  more  core  than  the  data  areas  defined.  Redefining 
work  areas  that  are  not  required  in  different  parts  of  the  program  would  also  reduce 
storage  requirements. 

Similarly,  application  program  procedure  divisions  offer  opportunities  for 
improvements.  They  can  be  better  organized  so  that  executed  COBOL  paragraphs  are 
physically  near  the  place  of  performance  in  core. 

Workload  Scheduling 

The  current  method  of  scheduling  batches  of  transactions  through  the  computer  is  a 
1 manual  process.  There  are  48  types  of  batches  queued  up  for  processing  (16  types  of 

r 

transactions  and  three  priorities  within  each). 

One  of  the  requirements  for  updating  the  data  base  is  to  have  a recovery  point  in  the 
event  a problem  is  encountered  while  the  update  is  in  process.  In  order  to  establish  such  a 
recovery  point,  all  updating  must  cease  and  a checkpoint  must  be  taken.  DLSC  has 
established  the  checkpoint  frequency  at  one  hour.  Operating  experience  has  been  used  to 

I 

set  the  maximum  batch  size  such  that  the  processing  time  would  average  one  hour  per 
batch.  Some  types  of  transactions  contain  2,000  actions  per  batch,  while  batches  for 
other  types  of  transactions,  which  require  more  processing  time,  contain  1,500  actions. 

I 

The  high  priority  transactions  (priority  1 and  2)  are  batched  every  half  hour  and 
therefore  rarely  reach  the  maximum  batch  size.  Many  high  priority  batches  were 
observed  containing  only  one  transacton. 

The  computer  operator  monitors  the  48  queues  and  manually  selects  the  batch  to  be 
processed  next.  He  is  aided  by  a listing  that  reflects  the  relative  priority  of  batches 
awaiting  processing.  i 

In  order  to  take  advantage  of  the  multiprocessing  capability  of  the  Burroughs 
computer,  several  batches  are  processed  concurrently.  The  current  system  requires  that  | 

1 
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the  processing  be  completed  for  all  batches  updating  the  data  base,  in  order  to  establish  a 
recovery  point.  While  the  processing  time  averages  one  hour  per  fuU  batch,  the  actual 
time  required  to  process  each  batch  varies  greatly.  A significant  amount  of  computer 
time  is  therefore  lost  between  the  time  the  first  batch,  operating  concurrently,  is 
completed  and  the  time  the  last  batch  is  completed.  DLSC  has  estimated  that  on  the 
average  22.5%  of  the  residence  time  of  the  three  queues  is  not  utilized  properly  because 
of  this  practice.  This  process  is  made  more  inefficient  by  the  preemptive  introduction  of 
high  priority  transaction  queues,  which  rarely  reach  maximum  batch  size. 

Members  of  the  DLSC  staff  have  a project  under  development  that  will  allow  a time 
dependent  checkpoint  to  be  taken  without  waiting  for  a batch  to  terminate.  The  project 
offers  other  advantages,  such  as  allowing  larger  batches  to  be  generated,  thereby  saving 
the  overhead  involved  in  the  termination  and  initiation  of  batches. 

DIPS  Data  Base 

The  TIR  data  base  was  found  to  be  organized  efficiently  for  processing  transactions 
where  the  National  Item  Identification  Number  (NUN)  was  known.  The  data  base  is 
organized  so  that  the  NUN  itself  points  to  the  location  on  DISC  storage  where  the 
information  ab^^ut  the  NUN  is  stored.  Given  a NUN,  the  computer  can  quickly  and 
efficiently  retrieve  the  desired  data.  This  same  degree  of  efficiency  does  not  exist, 
however,  for  processing  transactions  where  the  NIIN  is  not  included  as  a part  of  the 
transaction  search  argument. 

For  this  study,  the  only  statistics  available  that  reflected  compute  processing  time 
by  data  base  segment  were  for  the  7.5  hour  period  from  9:08  to  16:38  on  February  7,  1977. 
During  this  period,  47%  of  the  computer  input/output  time  used  for  data  base  processing 
was  spent  on  transactions  that  did  not  include  a NIIN. 
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Statistics  for  the  months  of  November  and  December  1976  and  January  1977 
* indicated  that  24%  of  aU  inquiry  transactions  did  not  include  the  NUN  as  a part  of  the 

transaction  search  argument. 

DIPS  Workload  Policy  and  Priority  Considerations 

Changes  in  policy  and  procedure  could  smooth  and  control  the  current  and  projected 
DIDS  workload.  In  general,  such  changes  would  require  the  concurrence  of  DLA,  OSD,  and 
other  affected  organizations.  The  central  issue  is  to  reduce  the  irregularities  in  the 
workload  on  the  Prime  B6700  and  to  relieve  the  congestion  in  the  processors. 

The  DIPS  transactions  workload  now  consists  of  several  different  transaction  types 
(Interrogations,  Search,  New  Issues,  IIM,  CMDN,  IIM  Triggers,  CMDN  Triggers)  that  are 
processed  within  a four-level  priority  scheduling  structure.  The  average  monthly 

r 

transaction  workload  is  about  2.35  million,  of  which  less  than  0.5%  are  priority  1 (to  be 
processed  within  4 hours  of  receipt),  about  10%  are  priority  2 (to  be  processed  within 
’ 12  hours  of  receipt),  about  10%  are  priority  3 (to  be  processed  within  48  hours  of  receipt), 

and  about  73%  are  priority  4 (to  be  processed  within  72  hours  of  receipt).  The  usual 
technique  is  to  allow  the  transactions  to  age  until  they  approach  2 hours  of  their  priority 

I 

response  threshold  before  they  are  processed. 

As  the  priority  1 and  2 transactions  are  received,  they  are  introduced  in  a 
preemptive  manner  into  the  workflow,  necessitating  operator  and  processing  adjustments. 

The  result  is  that  the  workflow  is  not  as  smooth  as  it  could  be,  and  additional  processor 
resources  are  consumed.  An  alternative  is  to  use  a simple  24-hour  response  time 
requirement  for  all  transactions.  This  would  allow  for  a smoother  scheduling  of  the  work, 

I but  would  require  an  adjustment  on  the  part  of  the  priority  1 and  priority  2 DIDS 

customers. 

Based  on  the  aggregate  statistics  available,  it  is  not  clear  that  the  effects  on  users 
. would  be  too  severe.  For  example,  DIDS  December  27,  1976,  to  January  28,  1977, 

‘ statistics  on  monthly  processing  indicate  that  71%  and  89%  of  the  priority  1 and  priority  2 
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transactions,  respectively,  were  processed  within  their  time  thresholds.  On  the  average, 
some  13,400  priority  1 and  60,600  priority  2 transactions  per  month  were  not  processed 
within  their  priority  time  goal.  Based  on  the  DIDS  statistics  in  Follow-Up  Transactions 
(which  are  inquiries  about  previously  submitted  transactions),  we  found  that  an  average  of 
about  6,250  such  inquiries  were  made  over  the  30-day  period  following  the  inquiries.  Even 
if  they  were  related  only  to  priority  I's  and  2's,  the  total  follow-up  inquiries  amount  to 
less  than  10%  of  the  priority  1 and  priority  2 transactions  that  were  not  processed  within 
their  priority  goals. 

Everyone  who  does  not  receive  a response  within  the  appropriate  priority  time  does 
not  submit  a follow-up  request,  of  course.  At  the  very  least,  however,  these  data  suggest 
that  the  user  requirements  for  priority  1 and  priority  2 time  responses  are  questionable. 
A.lso,  we  note  that  statistics  on  totsd  follow-up  transactions  indicate  that  less  than  2596  of 
them  are  submitted  within  30  days  of  their  submitted  date.  These  data  are  tabulated  in 
Table  15. 


TABLE  15.  STATISTICS  ON  FOLLOW-UP  TRANSACTIONS 


Date  of  Processing 

Date  Range  For  Foilow-ups 
That  Matched  (Davs) 

Over  90  Days 
Or  Not 
Matched 

Total 

1 to  30 

31  to  60 

61  to  90 

77020 

838 

20 

10 

750 

1,618 

77022 

1,925 

105 

1 

10 

2,041 

77023 

1,332 

206 

0 

339 

1,773 

77024 

49 

1,185 

3 

5,313 

6,555 

77025 

46 

143 

1 

506 

696 

77026 

138 

32 

6 

582 

758 

77028 

24 

59 

0 

1,822 

1,905 

77029 

336 

3 

3 

102 

444 

77030 

573 

404 

13 

599 

1,594 

77031 

3 

136 

0 

460 

649 

77032 

393 

39 

100 

517 

1,143 

77033 

127 

0 

0 

149 

276 

77034 

99 

1,275 

4 

5,412 

6,790 

77035 

316 

26 

0 

760 

1,102 

77036 

4 

0 

0 

12 

16 

77037 

44 

65 

0 

475 

584 

77038 

0 

86 

0 

0 

36 

TOTALS 

6,252 

3.S34 

U1 

17,913 

23,140 

PER  DAY 

345 

- 

- 

' 

- 

% OF  TOTAL 

, 2 

.0U5 

63.7  1 

100% 

Source:  DLSC 
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Additionally,  offloading  from  the  Primary  B6700  system  wiU  contribute  to  smoothing 
its  workload.  DLSC  plans  to  utilize  the  ARS  file  on  the  IBM  360/65J  would  allow  this  kind 
of  adjustment  in  the  Primary  B6700  workload. 
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III.  ASSESSING  THE  OPTIONS  TO  DEAL  WITH  THE  CONSTRAINTS 
ON  DIDS  PROCESSING  CAPABILITY 


In  this  chapter,  we  discuss  the  basic  options  considered  for  solving  the  current  DIDS 
processing  capability  problems.  All  of  these  options  deal  principally  with  the  supply  or 
capacity  side  of  the  DIDS  workload.  None  of  them  deals  explicitly  with  ways  to  reduce 
the  workload  volume  to  be  processed.  Consideration  of  the  demand  (workload  generation) 
side  of  the  DIDS  workload  is  outside  the  scope  of  this  task,  but  it  is  clearly  an  important 
part  of  the  total  systems  assessment  of  DIDS. 

We  reviewed  five  options  from  the  viewpoint  of  their  feasibility  (Is  it  possible?), 
\ practicability  (Will  it  work  well?),  and  relative  cost.  We  did  not  perform  detailed  cost- 

benefit  einalyses.  The  five  options  include:^ ^ 

One  “ Maintenance  of  the  status  quo 

Two  - Use  of  off-site  computer  facilities 

Three  - Augmentation  of  the  Primary  B6700  with  larger  Burroughs  computers 

Four  - Augmentation  of  the  Secondary  B6700  as  proposed  and  offloading  of  work 

from  the  Primary  B6700 

Five  - Optimization  and  limited  hardware  changes  to  increase  the  effectiveness 
of  current  machines 

< 

OPTION  ONE  - MAINTENANCE  OF  THE  STATUS  QUO 
. The  essence  of  Option  One  is  to  leave  the  EDP  systems  as  currently  configured  and 

to  continue  with  minimeil  or  no  application  program  optimization.  The  current  workload 
congestion  would  continue,  and  probably  gradually  worsen,  due  to  the  saturation  of  the 
Primary  B6700.  While  this  option  is  feasible  (DLSC  is  operating  this  way  now),  it  is  not 

^^We  note  that  we  do  not  consider  any  options  that  would  require  any  new 
equipment  or  replacements  of  equipment  not  compatible  with  Burroughs'  hardware. 


H-.j.LaT)rrC  FIU2D 


judged  practicable  by  either  DLSC  or  DIDS  users.  VVe  concur  that  the  option  is  not  viable 
and  does  not  merit  further  consideration. 

OPTION  TWO  - USE  OF  QFF-SITE  COMPUTER  FACILITIES 

Option  Two  would  make  use  of  EDP  resources  compatible  with  the  B6700  at 

installations  where  computer  time  could  be  purchased  piecemeal.  DLSC  has  tried  this 

option;  in  1976,  some  566  hours  were  used  on  the  State  of  Michigan  Treasury 

Department's  B6700  installation.  We  question  the  feasibility  of  transporting  sufficient 

DIDS  work  to  an  off-site  facility  to  affect  the  workload  saturation  on  the  Primary  B6700 

significantly.  As  DLSC  has  noted,  the  logistics  are  complex  and  costly.  This  option  only 

makes  sense  for  those  emergency  situations  in  which  an  alternate  relocation  site  is 

essential  for  continuance  of  minimal  DIDS  processing.  For  the  alleviation  of  a daily 

workload  saturation  problem,  use  of  off-site  facilities  is  impracticable. 

OPTION  THREE  - AUGMENTATION  OF  THE  PRIMARY  B6700  WITH  LARGER 
BURROUGHS  COMPUTERS 

For  Option  Three,  only  Burroughs-compatible  equipment  have  been  considered. 

As  currently  configured,  the  Primary  B6700  has  the  maximum  number  (3)  of  CPUs, 
and  is  about  at  the  maximum  in  memory  modules  and  physical  connections  to  mass  storage 
devices.  Increasing  the  memory  to  the  maximum  (to  6 megabytes  from  the  current 
4.7  megbytes),  or  adding  additional  peripheral  storage  would  not  change  the  processor 
bottleneck  situation. 

As  a means  of  roughly  sizing  the  potential  costs  of  this  option,  we  considered 
reconfiguring  the  DLSC  existing  and  functionally  separate  B6700  computer  systems  into 
an  integrated  system  via  a Burroughs  Global  Memory  with  a B6800  single  CPU  computer. 
In  this  integrated  configuration,  all  six  CPUs  (three  on  the  primary  B6700,  two  as  the 
Secondary  B6700,  and  one  on  the  B6800)  can  have  access  to  the  TIR.  For  the  smallest 
B6800  processing  system  (the  B6807)  with  the  minimum  Global  Memory  (~1.5  MB),  and 
retaining  both  B6700  systems,  this  augmentation  is  estimated  to  cost  $1,104,000  (in 
1977  dollars).  If  the  next  larger  B6800  system  (the  B6811)  and  the  maximum  Global 
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Memory  (~3  MB)  are  used,  this  augmentation  is  estimated  to  cost  $1,768,000  (in  1977 
dollars).  These  options  are  tabulated  in  Table  16.  These  augmentations  would  provide 
between  two  to  four  times  the  capacity  of  the  current  DLSC  DIDS  workload  processing 

1 9 

potential.  Further,  they  are  no  more  costly  and  an  order  of  magnitude  more  effective 
them  the  augmentation  of  the  Secondary  B6700  proposed  by  DLSC.  Both  of  these 
augmentations  maintain  full  compatibility  with  the  existing  systems  for  minimal 
conversion  and  implementation  costs  and  time,  and  incorporate  the  potential  for 
additional,  substantial  growth.  For  either  of  these  configurations,  a 16-month  lead  time 
from  order  to  installation  is  estimated. 

This  option  does  not  offer  short-term  (3  to  6 months)  relief  for  the  Primary  B6700 

processor  saturation  problem.  If  the  long-term  prospects  for  the  DIDS  workload  exceed 

the  current  projections  and/or  call  for  continued  growth  throughout  the  1980-1990  period, 

then  this  option  or  its  cost-effective  equivalent  will  be  required.  Additionally  forecast 

and  analysis  of  workload  would  be  required  to  estimate  future  DIDS  requirements,  which 

opens  the  subject  to  considerations  of  growth  management  and  long-term  planning. 

OPTION  FOUR  - AUGMENTATION  OF  THE  SECONDARY  B6700  AS  PROPOSED 
AND  OFFLOADING  OF  WORK  FROM  THE  PRIMARY  B6700 

This  option  reflects  the  pending  DLSC  proposal  that  involves  the  changes  listed  in 

Table  17.  Based  on  an  unsolicited  proposal  from  the  Burroughs  Corporation,  the  estimated 

cost  for  the  equipment  (hardware)  shown  in  Table  16  is  $1,628,547  (in  1977  dollars),  with 

13 

an  additional  $56,710  for  maintenance,  installation  and  shipping  costs. 

This  augmentation  would  leave  the  Primary  B6700  essentially  in  its  current 
configuration,  but  almost  double  the  size  of  the  Secondary  B6700.  A comparison  between 
the  current  and  proposed  augmentation  of  the  Secondary  B6700  is  given  in  Table  18. 

12 

New  Product  Announcements.  B6800  Systems,  Business  Machine  Group,  Burroughs 
Corporation,  September  17,  1976. 

^^From  DSAH-LS,  Funding  Requirement  for  DLSC  ADD  B6700  Equipment 
Augmentation  Request,  November  18,  1976. 
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TABLE  16.  B6800  AND  GLOBAL  MEMORY  OPTIONS 


OPTION  A - MINIMUM  B6300  and  GLOBAL  MEMORY  CONFIGURATION 


B.ASIC  COMPONENT 

DESCRIPTION 

PURCH.ASE  PRICE 
(1977  DoUars) 

B8807  System 

1 Central  Processor,  6.7  MHz 

(1.5  A(s  main  memory  access) 

$ 227,000 

1 Input/Output  Processor  with  20  I/O  Channels 
1 Memory  Control 
1 Power  Supply 
1 Peripheral  Control  Cabinet 
1 Maintenance  Processor  and  Display 
1 Operator  Console  and  Control  with  Dual  Displays 


Main  Memory 

4 

B60Q9-5  Main  Memories  for  a total  of  1.5  Megabytes 

336.000 

Global  Memory  and  Control 

1 

B6009-11  Glbbal  Memory  and  Control  (786,432  bytes) 

238,000 

Additional  Global  Memory 

3 

B6009-12  Global  Memory  (786,432  bytes)  (This  and 
the  above  component  provide  -1.5  megabytes  of 
Global  Memory) 

205,440 

Globel  Memory  B6700  Interface 

1 

B6009-13 

47.136 

$1,103,576 

OPTION  B - LARGER  P6300  AND  GLOBAL  MEMORY  CONFIGURATION 

B5811  System  1 Central  Processor,  6.7  MHz  U50  ns  main  memory  access)  430,000 

1 Input/Output  Processor  with  20  I/O  Channels 
1 Memory  Control 

1 Power  Supply 

2 Peripheral  Control  Cabinets 

1 Maintenance  Processor  and  Display 
1 Operator  Console  and  Control  with  Dual  Displays 


Main  \ 

lemcry 

4 

B6C09-5  Main  Memories  for  a total  of  1.5  Megabytes 

336. COO 

Global 

Memory  and  Control 

1 

B6009-11  Glooal  Memory  and  Control  (786,432  bytes) 

S 238,000 

Additional  Global  Memory 

3 

B6009-12  Additional  Global  Memory  (2.359,296  bytes) 
(This  and  tne  above  component  provide  —3  Megabytes 
of  Global  Memory) 

616,320 

Global 

Memory  S5730  Interface 

1 

36009-13 

47,136 

$1,767,456 

Notes:  (1)  Option  A would  more  than  double  the  current  DIDS  computer  system  capacity,  if  both  DLSC  36700's  are 

interfaced  with  the  B6800  via  the  Global  Memory. 

(2)  Option  B would  more  than  triple  the  current  DIDS  computer  system  capacity,  if  both  DLSC  BSTOO's  a.-e 
interfaced  with  the  36800  via  the  Glooal  Memory. 

(3)  All  these  equipments  are  availaole  from  Burroughs  on  a monthly  lease  basis  is  well. 

14)  The  expected  availaoility  date  for  the  Global  Memory  is  March  1973. 


New  Product  Announcements.  B6300  Systems.  Business  Macnine  Group.  Burroughs  Cor'oration. 
beptemoer  :9T6,  ana  Uiscussions  with  Burrou5hs  personneL 
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TABLE  17.  REQUESTED  EQUIPMENT  TO  AUGMENT  DIPS  COMPUTER  SYSTEMS 


Equipment  to  be  Added  to  Secondary  B6700 


Qty 

Number 

Description 

1 

B6373 

Disk  File  Control  (Will  fit  in  existing  cabinet) 

1 

B6471 

Disk  File  Exchange  (WiU  require  new  cabinet,  no  cost, 
and  will  fit  alongside  current  system) 

2 

B6471-5 

Control  Adapter 

2 

B6471-6 

EU  Adapter 

1 

B6009-4 

Planar  Memory  with  Memory  Control  and  Testor 
(393,216  bytes  of  325ns) 

2 

B6009-5 

Planar  Memory  (393,216  x 2 = 786,432  bytes) 

3 

B9486-4 

Dual  Drive  Increments  (6  spindles)  (Will  fit  behind 
current  disk  packs) 

2 

B9383-8 

Dual  Disk  Pack  Controllers  with  5 dual  drives 
(10  spindles)  on  each  disk  pack  controller 

2 

B6393-2 

Tape  controls  (Will  fit  in  existing  cabinet) 

6 

B9393-3 

240  KB  PE  Tape  Drives 

4 

B6304-1 

Disk  Pack  Drive  Controller 

6 

B9495-5 

320/400  KB  Mag.  Tape  Unit  (9  CH-1600  BPI) 

2 

B6395-7 

320/400  KB  Mag.  Tape  Unit  Control 

1 

B6493-2 

PE  Tape  Exchange  (Fits  in  tape  drive) 

1 

B9499-12 

2x8  Master  Electronics  Exchange 

1 

TD830 

CRT  Display/Adapter 

Equipment  to  be  Added  to  the  Primary  B6700  System 


3 

B9486-4 

Dual  Drive  Increments  (6  spindles) 

1 

TD830 

CRT  Display/Adapter 

Equipment  Moved  From  Primary  B6700  System  to  Secondary  B6700  System 

1 

B9375-10 

HPT  Disk  File  (1  Electronic  Unit  (EU)  and  5 
Storage  Units  (SU)). 

Source:  DLSC,  Request  for  B6700  Equipment  Augmentation,  October  22,  1976. 
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Proposed  Configuration 
After  Augmentation 


Approximate 
Impact  On 
Configuration 


2 CPUs 

200  Megabytes  of  HPT  Disk 
Storage 

~2  Megabytes  of  Core 
(Memory) 

21  Disk  Packs 

22  1600  BPI  Tape  Drives 
1 CRT  TD830  Display/ Adapter 

The  central  issue  is  how  much  this  added  capability  will  relieve  the  CPU  congestion 
, on  the  Primary  B6700.  As  discussed  in  Chapter  II,  two  different  efforts  were  made  to 

estimate  the  likely  workload  volume  that  could  be  transferred  from  the  current  and 
projected  Primary  B6700  workload  to  the  Secondary  B6700.  Both  the  efforts  yielded 
estimates  of  about  85  hours  of  processor  time  per  month  as  the  likely  workload  that  could 
be  transferred.  That  would  amount  to  about  5.8%  to  7%  of  the  current  monthly 
Primary  B6700  processor  time  potentially  available  for  application  programs.  This 
. offloading  of  work  is  obviously  desirable,  and  while  it  will  help  relieve  the  Primary  B6700 

processor  bottleneck,  it  is  not  large  enough  to  solve  the  problem  by  itself. 

We  conclude  that  no  amount  of  equipment  augmentation  on  the  Secondary  B6700  will 
be  adequate  bv  itself  to  solve  the  congestion  problem  on  the  Primary  B6700.  Some  other 

k 


2 CPUs 

100  Megabytes 
of  HPT  Disk 
Storage 

~1  Megabyte 
of  Core 
(Memory) 

8 Disk  Packs 


10  1600  BPI 
Tape  Drives 


No  Change 
Double  Capacity 

Double  Capacity 

2i  - Fold  Increase 
in  Capacity 

Double  Capacity 
New 
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alternatives  must  be  pursued  in  addition  to  offloading  work  from  the  Primary  B6700  to  the 

14 

Secondary  B6700  if  the  DIDS  workload  bottleneck  is  to  be  relieved. 

OPTION  FIVE  - OPTIMIZATION  AND  LIMITED  HARDWARE  CHANGES  TO  INCREASE 
THE  EFFgCTIVENESS  of  CURRENT  MAgHlN15~ 

Given  the  current  DIDS  situation  and  assuming  the  DLSC  DIDS  workload  projections 
of  December  1976,  we  feel  that  this  option  is  the  most  effective  in  the  short  term  of  the 
five  considered.  It  is  feasible — both  DLSC  and  Burroughs  personnel  concur. 

Increased  efficiency  of  the  existing  system  could  be  achieved  by  optimization, 
smoothing  the  DIDS  workload,  reducing  the  CPU  congestion  in  the  Primary  B6700,  and 
offloading  a maximum  of  work  from  the  Primary  B6700  to  both  the  Secondary  B6700  and 
the  IBM  360/65J.  Limited  hardware  adjustments  would  be  necessary. 

We  estimate  that  improvements  of  10%  to  20%  CPU  utilization  on  the 
Primary  B6700  and  at  least  20%  on  the  Secondary  B6700  are  possible.  These 
improvements,  plus  a concerted  strategy  to  offload  work  to  the  Secondary  B6700  and 
IBM  360/65J,  will  relieve  the  current  CPU  congestion  on  the  Primary  B6700.  Basically, 
we  expect  Option  Five  to  achieve  everything  Option  Four  does,  in  addition  to  yielding 
additional  opportunities  to  increase  the  Primary  B6700  effectiveness,  and  at  less  cost. 

We  will  discuss  this  option  in  terms  of  the  actions  that  can  be  taken  on  the  different 
EDP  systems.  We  have  not  attempted  to  be  exhaustive  in  identifying  all  potentially  useful 
actions,  but  have  instead  listed  only  those  that  we  were  able  to  derive  or  infer  through  the 
study  analysis  and  on-site  observations. 

The  recommended  actions  are  presented  in  three  major  groups:  .Actions  for  the 
Primary  B6700,  Actions  for  the  Secondary  B6700,  and  Management  Improvements  Actions. 
The  presentation  sequence  in  each  group  indicates  roughly  the  preferred  ranking  of  the 
actions.  Table  19  summarizes  the  actions  by  indicating,  in  terms  of  a three  level 

^“^There  is  a subtle  issue  related  to  the  differences  between  wall  clock  hours  and 
processor  hours.  In  the  course  of  this  study,  we  observed  ratios  of  processor  time  in  hours 
to  wall  clock  hours  (roughly  equivalent  to  program  resident  time)  from  1:2  to  1:10. 
Consequently,  we  have  ignored  the  wall  clock  projections  and  concentrated  on  processor 
hours  as  the  measure  of  workload  processed.  This  issue  is  discussed  in  Action  20, 
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TABLE  19.  INCREASE  EFFECTIVENESS  OF  CURRENT  MACHINES 
THROUGH  OFllMlZATlON  AND  LIMITED  HARDWARE  CHANGES: 
RECOMMENDED  ACTIONS 


I 

L 


CRITERIA' 

ACTIONS^  ^ 

impact  On 
Primary  B5700 
Processing 
Congestions 

H - High 
M = Med 
L ’ Low 

Time  to 
Implement 
.Action 

S-M-L^ 

D LiC 
Resource 
(Personnel) 
Required 

H = High 
M » Med 
L 3 Low 

-Action 
.Approval  Or 
Dependency 
On  .Agencies 
Other  Than 
DLSC 

Software  Improvements 

1. 

Identity  the  Cause  of  and  Reduce  the 
Excessive  Volume  of  GEORGE  Calls 

H 

M 

- 

Burroughs 

2. 

Remove  MCP  Inefficiencies  in.  Processing 
Variable  Length  Data  Records'^ 

M 

M 

- 

Burrougrs 

3. 

Reduce  the  Pjeriodic  Peaking  of  Presence- 
Bit  Overhead"* 

L 

s 

L 

- 

4. 

Reduce  Excessive  DMS  II  Activity 

L-M 

M 

- 

Burroughs 

Application  Program  Improvements 

s. 

Modify  Trigger  Pile  PoUow-Op  Processing^ 

H 

M 

L 

DLA/OSD/DIDS 

Customers 

Modify  the  COBOL  Compiler  to  Handle 
Variable  Length  Records  More  Efficiently 

M-H 

M 

M 

Burroughs 

o 

o 

p- 

7 . 

Use  ALGOL  For  Selected  DLSC  Appli- 
cation Programs 

M 

S-L 

_5 

DLA/OSD 

>> 

3. 

Increase  the  Efficiency  pf  Programs 
Processing  the  T!R  File'* 

M 

S-L 

H 

- 

h. 

c. 

9. 

Increase  the  Efficiency  of  TIR  Accesses 
by  AFARS 

M 

L 

M 

- 

10. 



Reduce  the  Mumo^'’  of  Future  Update 
Records  Processed"* 

L 

M 

M 

- 

Improvements  in  the  DIDS  Data  Base 

11. 

Reduce,  the  Impact  of  Inquiries  Without 
a iraiT* 

M 

M 

t- 

DLA/OSD 

Increase  the  Efficiencv  of  Workload  Scheduling 

12. 

Implement  the  DLSC  Revised  Queuing/ 
Processing  Concept  with  a Time 
Dependent  Check  Point^ 

H 

M 

M 

DLA 

13. 

Utilize  Automated  Scheduling  for  36700 
Workloads^ 

M-H 

M 

M 

- 

14. 

Process  Only  Full  Batches^ 

M 

s 

M 

- 

Hardware  Chanies 

15. 

Modify  Primary  B6700  Hardware 

M 

s 

M 

OSDiDLA 

IS. 

Modify  Secondary  36700  Hardware 

- 

M-H 

3 

M 

OSD/DLA 

.So 

i r- 

Jop 

Shoo  Scheduling 

5 S 
3*** 

VJ 

17. 

Improve  the  Scheduling  of  Jobs  on  the 
Secondary  86700 

L 

M 

M-H 

- 

1.  Actioiu  la-'JO  dcalinsf  with  Ma/ia^ement  Impfove.'nenLs  if«  not  listed  p«cause  the:r  ifrpact  on  the  Primary  B6700  CPU 
congestion  is  indirect  and  long  term. 

2.  These  rankings  are  relative  to  the  set  of  I?  actions  considered  and  are  based  on  subjective  judgments. 

3.  S = short  term,  I to  3 months;  M = mid  term,  3 to  9 months:  L = long  term,  S to  12-plus  month's. 

4.  DL5C  has  similar  ideas  under  consideration  as  part  of  planned  actions  or  future  actions. 

5.  The  negligible  effort  indicated  is  for  new  programs.  For  the  conversion  of  old  programs  the  resource  requirements  wouid  oe 
high  (H). 
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qualitative  scale,  their  impacts  on  the  Primary  B6700  CPU  congestion,  implementation 
times,  and  DLSC  resource  requirements. 

Some  of  these  actions  are  dependent  on  other  actions,  while  others  are  independent 
or  mutually  exclusive.  Where  there  are  dependency  or  mutually  exclusive  relationships, 
we  have  tried  to  identify  them.  In  several  instances  we  have  listed  actions  that  DLSC 
either  has  considered  or  is  presently  considering,  and  we  have  tried  to  identify  this  fact. 

Primary  B6700  - Software  Improvements 

The  objective  of  these  software  improvements  is  to  reduce  the  Burroughs  Master 
Control  Program  (MCP)  and  Data  Management  System  (DMS)  consumption  of  processor 
resources  from  the  current  25%  to  40%  level  to  a more  satisfactory  20%  level. 

Action  1.  Identify  the  Cause,  and  Reduce  the  Volume  of,  GEORGE  Calls 

Implementing  this  action  requires  a modification  to  the  MCP  to  collect  the 
data  necessary  to  determine  what  is  invoking  the  GEORGE  calls.  Currently,  the  number 
of  GEORGE  calls  is  400  to  500  calls  per  second.  For  the  DIDS  application,  a rate  of 
100  calls  per  second  is  considered  to  be  an  acceptable  upper  bound.  Reducing  the  number 
of  calls  per  second  will  contribute  to  the  reduction  of  the  current  overhead  in  the 
Primary  B6700.  DLSC-D  will  require  Burroughs  assistance  to  make  the  required  software 
modification,  and  to  achieve  more  effective  processor  and/or  application  program 
synchronization. 

Action  2.  Remove  MCP  Inefficiencies  in  Processing  Variable 
Length  Data  Records 

DLSC  has  been  concerned  about  this  problem  for  some  time.^^  Any  COBOL 
READ  or  WRITE  statement  on  the  B6700  entails  a movement  of  data  in  core  either 
to/from  the  MCP  buffer  to  the  "01"  area  in  memory  that  identifies  the  recorded 
description.  When  a READ  INTO  or  WRITE  FROM  is  used,  two  data  movements  in 
memory  are  necessary.  Unless  explicitly  avoided,  data  of  variable  lengths,  are  moved 

^^DLSC  has  apprised  Burroughs  of  this  problem. 
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character  by  character,  under  the  Burroughs  word  length  used  to  define  the  receiving 
field.  Any  portion  of  the  receiving  field  not  filled  with  the  moved  data  is  then  blanked 
out.  This  causes  inefficiencies  in  the  use  of  both  processor  resources  and  core  (memory). 
Since  an  estimated  10%  to  20%  of  the  DIDS  daily  workload  (e.g.,  all  input  inquiries  and 

I 

searches)  processing  involve  variable  length  records,  this  is  a significant  problem, 
especially  when  a sort  is  required.  Currently,  the  B6700  software  will  "pad"  out  all 
variable  length  data  records  to  a fixed  size  prior  to  processing  the  sort.  The  fixed  size  is 
set  for  the  largest  possible  occurrence  of  a record  size.  For  DIDS  data  records  that  can 
typically  range  from  less  than  20  to  over  6,600  characters  in  length,  the  sort  can  be  very 
inefficient. 

% 

In  a DLSC  experiment,  a COBOL  program  entailing  a READ,  RECORD,  CHECK, 
REMOVAL  of  a bad  record,  and  a WRITE  was  run  on  the  Primary  B6700  and  the 
IBM  360/65J.  The  data  were  variable  length  records.  In  that  experiment,  the  IBM  360/65J 
required  considerably  less  than  one-half  of  the  Primary  B6700  processing  time  to  perform 
the  identical  tasks.  The  differences  are  judged  to  be  principally  a function  of  the  ability 
of  the  two  machines  and  their  software  to  handle  variable  length  records. 

Two  strategies  could  reduce  the  inefficiences  related  to  processing  variable 
length  records.  The  first  is  to  modify  the  software  (both  MCP  and  the  COBOL  compiler) 
so  that  it  handles  variable  length  records  more  efficiently.  This  will  require  assistance 
from  Burroughs  who  currently  has  the  problem  under  study.  The  second  strategy  is  related 
to  Action  9 under  the  Application  Program  Improvements. 

1 6 

Action  3.  Reduce  the  Periodic  Peaking  of  Presence-Bit  Overhead 

The  most  straightforward  way  to  reduce  this  peaking  is  to  maintain  a better 
mix  of  programs  in  the  system.  The  intent  is  to  avoid  the  "thrashing"  that  periodically 
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DLSC  has  noted  this  problem  in  their  optimization  efforts. 
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occurs  and  unnecessarily  uses  processor  resources  for  job  management  overhead.  This 
action  is  related  to  Action  14  under  Application  Program  Improvements. 

Action  4.  Reduce  Excessive  DMS  II  Activity 

We  suspect  that  a significant  portion  of  the  overhead  consumption  of  the 
Primary  B6700  processor  resources  is  attributable  to  DMS  II.  The  intent  of  this  action  is 
to  determine  whether  changes  in  DMS  II  usage  would  reduce  the  amount  of  processor 
activity  for  DMS  II.  Implementing  this  action  will  require  a software  modification  to 
provide  the  data  necessary  to  account  for  all  DMS  II  activity.  These  modifications  would 
be  best  made  by  Burroughs,  as  DMS  II  is  part  of  their  proprietary  software. 

Primary  B6700  - Application  Program  Improvements 

Processing  TIR  records  consumes  more  of  the  computer  resources  than  any  other 
application  area.  Specific  improvements  can  be  effected  through  an  improved  interfacing 
between  AFARS  and  application  programs  and  more  effective  processing  of  the  TIR.  The 
following  actions  are  examples  of  changes  that  should  be  made. 

17 

Action  5.  Modify  Trigger  File  Follow-Up  Processing 

Trigger  transactions  are  created  for  each  future  update.  They  are  used  for 
two  purposes:  1)  to  change  a future  update  to  a current  (i.e.,  active)  update,  and  2)  to 
initiate  the  notification  required  when  this  change  is  made.  These  are  high  volume 
transactions  that  currently  must  be  processed  near  the  15th  and  end  of  the  month.  This 
twice-a-month  requirement  seriously  affects  the  normal  transaction  processing. 

The  change  from  future  update  to  current  updating  could  be  handled  as  part  of 
daily  processing.  The  next  time  that  the  TIR  record  requires  a content  change  under 
normal  processing,  it  could  first  be  checked  for  future  updates  on  past  dates;  the  changes 
could  then  be  effected  immediately.  This  would  require  some  additional  processing  and 

T7 

DLSC  has  explored  similar  ideas  in  the  past.  Proposals  are  being  developed  by 
DLA/DLSC  for  Service/Agency  and  MRA&L  review. 


perhaps  a larger  future  file,  but  a significant  portion  of  trigger  transaction  processing 
eliminated.  Two  variants  of  the  notification  process  can  be  considered. 

Off-Line  Notification  - The  notification  portion  of  the  process  can  be  handled 
completely  outside  of  the  TIR.  Currently,  notification  is  made  both  when  the  future 
update  is  made  and  on  the  effective  date  as  well.  By  saving  the  initial  notification  and 
reissuing  it  on  the  effective  date  (e.g.,  from  a tape  file),  this  second  notification  can  be 
accomplished  other  than  on  the  Primary  B6700. 

Eliminate  Effective  Date  Notification  - Consideration  should  be  given  to 
eliminating  effective  date  notifications  altogether,  since  the  users  concerned  will  already 
have  been  notified  during  the  initial  update  processing.  We  recognize  that  this  is  an 
extreme  action,  but  nonetheless  it  should  be  considered. 

1 A 

Action  6.  Modify  the  COBOL  Compiler  to  Handle  Variable  Length  Records 
More  Efficiently 

This  action  would  improve  the  processing  of  variable  length  records  and  the 
utilization  of  work  areas  and  reduce  the  overhead  processing  for  COBOL  programs. 

Action  7.  Use  ALGOL  for  Selected  DLSC  Application  Programs 

Instead  of  COBOL,  ALGOL  should  be  considered  as  the  DIDS  application 
programming  language  for  those  few  programs  which  account  for  80%  of  the  DIDS 
workload.  The  B6700  architecture  is  designed  with  the  ALGOL  structure  in  mind,  and 
ALGOL-coded  programs  are  processed  more  efficiently.  Not  only  will  this  conversion  to 
ALGOL  increase  the  efficiency  of  the  processing,  but  it  will  also  reduce  the  MCP  and 
COBOL  compiler  inefficiencies  in  handling  variable  length  records  (Action  6),  the  number 
of  GEORGE  calls,  and  possibly  the  P-BIT  activity. 

19 

Action  8.  Increase  the  Efficiency  of  Programs  Processing  the  TIR  FILE 

The  use  of  CAUSE,  WAIT  and  RESET  commands  could  be  changed  to  allow 

more  asychronous  processing.  For  the  application  programs  examined,  the  CAUSE 
T8 

DLSC  has  similar  ideas  under  consideration  as  part  of  planned  actions  or  future 

actions. 
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statement  is  immediately  followed  by  the  WAIT  and  RESET  statements  and  no 
asychronous  processing  is  accomplished.  Hence,  the  advantages  of  re-entrant  processing 
are  lost. 

20 

Action  9.  Increase  the  Efficiency  of  TIR  Accesses  by  AFARS 
An  entire  TIR  entry  could  be  built  with  only  one  access  to  AFARS.  Currently, 
an  entire  TIR  can  be  retrieved  only  one  segment  at  a time,  and  one  subsegment  at  a time 
for  multiple-sectioned  segments.  The  update  program,  for  example,  requires  all  segments 
for  editing.  Each  such  retrieval  is  a separate  invocation  of  AFARS.  Similarly,  when 
updating  or  record  creation  takes  place,  each  segment  to  be  updated  or  created  must  be 
passed  to  AFARS  separately.  Allowing  the  application  program  to  access  AFARS  only  to 
retrieve  or  update  an  entire  TIR  entry  wc  'Id  be  an  improvement.  In  those  instances  when 

only  one  segment  is  required,  the  current  technique  is  effective. 

• 21 
Action  10.  Reduce  the  Number  of  Future  Update  Records  Processed 

Reduced  processing  of  TBZR  segments  could  reduce  processing  requirements. 

These  segments  in  the  TIR  contain  data  needed  for  future  owner  information.  Presently, 

if  a single  future  update  is  to  be  made,  a TBZR  segment  is  produced.  If  a second  future 

update  is  entered,  then  a TBZH  is  created  for  both  updates  and  the  TBZR  is  deleted.  If  a 

TBZH  were  created  in  the  first  place,  the  redundant  process  of  creating  and  deleting  a 

record  could  be  eliminated. 

) 

Primary  B6700  - Improvements  in  the  DIPS  Data  Base 

The  TIR  data  base  is  organized  quite  efficiently  for  processing  transactions  where 
the  NUN  is  known.  This  same  degree  of  efficiency  does  not  exist  for  processing 
transactions  where  the  NIIN  is  not  included  as  a part  of  the  transaction  search. 


See  Footnote  18. 


See  Footnote  18. 
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Action  11.  Reduce  the  Impact  of  Inquiries  Without  a NUN 


- Collect  and  maintain  statistics  that  can  be  used  to  measure  the  degree  of 
efficiency  with  which  each  segment  of  the  data  base  is  accessed. 

- Investigate  alternative  methods  of  cross  referencing  part  number  to  NUN 
within  the  data  base. 

- Process  all  inquiries  without  a NUN  as  a special  batch  job  within  a 24-hour 
response  time  priority  rule. 

Primary  B6700  - Workload  Scheduling  Improvements 

The  current  method  of  scheduling  batches  of  transactions  through  the  computer  is  a 
manual  process.  There  are  48  types  of  batches  queued  up  for  processing  (16  types  of 
transactions  and  3 priorities  within  each). 

One  of  the  requirements  for  updating  the  data  base  is  to  have  a recovery  point  in  the 
event  a problem  is  encountered  while  the  update  is  in  progress.  To  establish  such  a 
recovery  point,  aU  updating  must  cease  and  a checkpoint  be  taken.  In  the  current 
Primary  B6700  system  several  batches  are  processed  simultaneously,  and  the  time  to 
process  each  batch  varies  greatly,  due  to  the  different  sizes  of  the  queue  and  the 
checkpoint  logic.  Opportunities  to  process  additional  transactions  (like  those  in  the  queue) 
are  consequently  lost,  and  the  average  transaction  service  turnaround  time  (elapsed  time) 
is  greater  than  it  should  be. 

Action  12.  Implement  the  DLSC  Revised  Queuing/Processing  Concept  with^^ 
Time-Dependent  Checkpoint 

DLSC  has  a project  under  development  that  allows  a time-dependent 
checkpoint  to  be  taken  without  waiting  for  a batch  to  terminate.  The  project  offers  other 
advantages,  such  as  allowing  larger  batches  to  be  generated  (see  Action  9),  thereby  saving 
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the  overhead  involved  in  the  termination  and  initiation  of  batches.  This  project  offers  a 
greater  immediate  potential  for  improving  transaction  throughput  than  any  other  system 
change.  Improvement  of  the  system's  capability  to  select  the  transactions  to  be  processed 
in  priority  sequence  should  be  part  of  the  project.  Sufficient  resources  should  be  assigned 
to  complete  the  project  as  soon  as  possible,  and  ALGOL,  rather  than  COBOL,  should  be 
the  programming  language  required. 

Action  13.  Utilize  Automated  Scheduling  for  B6700  Workloads^'* 

This  action  depends  upon  the  implementation  of  Action  12,  because  the  full 
benefits  of  automated  scheduling  will  be  best  achieved  in  conjunction  with  the  improved 
transaction  queuing/processing  concept.  In  order  to  have  the  scheduling  take  place 
remotely.  Action  15  must  also  be  implemented. 

Action  14.  Process  Only  Full  Batches 

The  way  in  which  high  priority  transactions  are  batched  should  be  modified  to 
allow  full  batches  rather  than  many  small  batches,  which  are  costly  in  terms  of  queue 
management  and  computer  overhead.  One  method  of  accomplishing  this  is  by  filling  the 
high  priority  batches  to  their  predetermined  maximum  with  lower  priority  transactions 
whenever  less  than  the  maximum  number  of  high  priority  transactions  is  available.  Since 
Action  12  implies  that  only  full  batches  will  be  processed,  this  action  is  really  only  a 
short-term  alternative. 

Primary  B6700  - Hardware  Changes 

Actions  15  and  16  are  variations  of  the  proposed  DLSC  ADP  Augmentation  Plan.  We 
estimate  that  total  additional  hardware  costs  would  be  from  $350,000  to  $400,000  in 
1977  dollars. 


24 
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See  Footnote  18. 


Action  15.  Modify  the  Primary  B6700  Hardware 


I The  Primary  B6700  hardware  should  be  augmented  by  adding  the  remote 

Cathode  Ray  Tube  (CRT)  display/adapter  for  scheduling  and  by  removing  the  excess 
100  megabytes  of  Head  Per  Track  (HPT)  Disk  Storage.  After  the  100  megabytes  of  HPT 
are  moved,  the  Primary  B6700  will  still  have  400  megabytes  of  the  HPT  mass  storage. 
The  remote  display/adapter  will  aid  in  the  automated  scheduling  of  the  workload  on  the 
Primary  B6700.  This  capability  will  help  smooth  the  workload. 

Based  on  our  analysis  that  the  critical  bottlenecks  are  the 
Primary  B6700  CPUs,  adding  3 more  disk  packs  will  not  improve  that  situation.  The  disk 
pack  mass  storage  current  capacity  on  the  Primary  B6700  is  apparently  adequate.  There 
are  now  66  dual  drive  disk  packs  with  174.4  megabytes  each,  for  a total  of  11.5  billion 
^ characters  of  on  line  disk  pack  mass  memory.  This  equates  roughly  to  about  11  billion 

characters  of  usable  storage,  of  which  about  8 billion  are  currently  required  by  the  DIDS 
, TIR  data  base. 

Secondary'  B6700  - Hardware  Changes 

All  the  software  and  virtually  all  the  application  program  actions  noted  for  the 
‘ Primary  B6700  apply  to  the  Secondary  B6700.  The  two  actions  noted  for  the 

Secondary  B6700  focus  on  changes  to  its  hardware  and  improvement  of  its  workload 
scheduling. 

• Action  16.  Modify  the  Secondary  B6700  Hardware 

The  Secondary  B6700  should  be  modified  by  adding  1 megabyte  of  core 
(memory),  100  megabytes  of  HPT  mass  storage  memory  (from  the  Primary  B6700)  and  the 
remote  CRT/display  console.  This  modification  is  different  from  the  one  described  in  the 
ADP  augmentation  proposal.  (See  Option  Four.)  All  the  TIR  data  processing  and  updating 
would  still  have  to  be  done  on  the  Primary  B6700.  Based  on  our  analysis,  only  about  5.8% 
to  7%  of  the  Primary  B6700  workload  (in  processor  hours)  could  be  transferred  to  the 
Secondary  B6700,  regardless  of  how  large  it  is  made. 


The  rationale  for  our  proposed  augmentation  is  as  follows: 


r 


- Currently,  the  Secondary  B6700  is  memory-bound.  That  bottleneck  causes 
the  CPUs  to  be  idle  about  50%  of  the  time.  Doubling  the  current 
1 megabyte  of  core  would  allow  fuller  utilization  of  the  currently  idle 
CPUs. 

- The  Secondary  B6700  now  has  only  one  electronic  unit  (EU)  for  its 
100  megabytes  of  HPT  disk  storage.  The  additional  100  megabytes  of  HPT 
would  double  the  capacity  of  this  mass  storage  medium  and  add  one  more 
EU.  The  additional  EU  will  provide  needed  redundancy,  and  the  extra 
100  megabytes  will  provide  additional  useful  storage  space. 

- The  console /display  device  will  enhance  the  ability  to  schedule  the 
Secondary  B6700  workload.  However,  given  the  nature  of  the  work  on  this 
system,  the  real  justification  for  adding  such  a remote  console  is  that  it 
will  provide  a useful  test  bed  for  new  scheduling  concepts  intended  for  the 
Primary  B6700. 

This  action  does  not  include  the  other  changes  to  the  Secondary  B6700  in  the 
pending  request.  The  basic  reasons  for  not  including  all  the  disk  and  tape  mass  storage 
devices  are  outlined  briefly  in  Table  20.  AU  the  workload  to  be  transferred  will  fit  on  the 
Secondary  B6700  as  currently  configured.  The  thrust  of  the  augmentation  proposal  is  to 
have  sufficient  capacity  for  almost  all  the  applications  both  old  and  new,  to  reside 
concui'’*ently  in  the  system.  Since  the  majority  of  the  new  workload  to  be  transferred  is  to 
be  processed  on  an  "as  required"  basis,  it  can  be  processed  on  the  current  configuration 
with  an  improved  scheduling  procedure.  More  mounting  and  dismounting  of  disks  and 
tapes  will  be  necessary,  but  this  is  a standard  procedure  in  job  shop-type  applications. 
This  notion  is  discussed  further  in  Action  17. 
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TABLE  20. 

BRIEF  ASSESSMENT  OF  PROPOSED  MASS  STORAGE  DEVICES 
rUR  SECONDARY  B6700  AUGMFNTATION 

Frcposed  .A  jg*nenu::cn 
To  Secondarv’  33700 
Hardware* 

BRIEF  .Assessment  of  .Augmentation  Proposed 

Disk  ra>As 

3 

(-  523MB) 

- 

To  Facilitate  Processing 
of  current  Workload 

• No  L'O  contention  was  observed  on  this  system. 

3 

(-■  523MB) 

6 

FUG  Revisions 

• This  work  involves  doth  testing  ahd  production  processes. 

• The  FUG  Revision  entails  updating  the  FUG  Master  File  for  either  specific  or 
mass  changes. 

• CurrenUy,  the  Secondary  B6700  can  hold  1 FUG  without  removing  any  disk 
packs.  The  intent  :s  to  load  4 FUGs  on  the  system  at  one  time  on  disk  packs. 
However,  FUG  Revisions  are  strictly  a tape  oriented  process  and  an  off-line 
activity  that  can  rve  ione  on  an  "as  required"  oasis  and  it  can  be  off-line 

for  extended  periods  of  lime.  This  process  can  be  carried  out  without  additional 
mass  storage  with  mounting  and  dismounting  of  disks  and  tapes  on  the  current 
configuration. 

• The  test  keys  and  parametric  screening  process  is  stnckly  a testing  application. 

f The  proposal  is  to  load  4 full  FIICs  on  the  disk  packs  for  testing. 

• Since  this  is  a testing  application  it  is  more  reasonaole  to  utilize  a statistical 
sample  of  the  FIIGs.  This  way  all  the  unique  FUG  cnaracteristics  could  be 
loaded  as  well  as  a statistical  sample  to  insure  95%  or  99%  confidence  in  the 
test.  One  existing  disk  pack  could  handle  3 or  3 FUGs  this  way. 

3 

PAC  Summaries 

• This  work  involves  a production  process. 

• It  is  essentially  a tape  operation  with  a disk  sort  that  is  done  on  an  "as 
required"  basis  and  can  fit  on  the  existing  configuration  with  improved 
scheduling. 

li 

u 

Orgar.Uational  Entity 

. This  woric  is  a produc'.ion  process  n wnioh  the  maintenance  of  the  OE  file 
will  be  done  on  the  Secondary  B6200. 

• The  main  reason  for  the  ’.apes  is  to  physically  separate  the  different  products 
generated. 

a With  improved  scheduling  this  process  can  fit  on  the  current  system. 

3 

12 

Edit  Guide 

• This  process  is  basically  an  "adit"  of  the  Edit  Guide  rules  used  in  the  FIGGs  to 
catalog  and  describe  items. 

• With  improved  scheduling  this  process  can  fit  on  the  current  system  and  run 
on  an  "as  required"  baSiS. 

< 1 
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MAIL/SORT  Suspense 

• This  is  a production  process  and  is  a tape  based  operation  that  can  fit  on  the 
current  configuration. 

• This  process  is  run  on  an  "as  required"  oasis. 

Civil  .Agencies  Catalogs 

• This  is  a production  process  which  manipulates,  decodes,  reformats  information 
extracted  from  tne  Master  Fi^e. 

• This  process  is  done  on  in  "as  required"  basis  and  it  aopears  logical  to  pul 
the  entire  process  on  the  IBM  360/63J  because  it  involves  publications. 

<1 

7 

History  Process 

• This  is  a production  process  that  is  a tape  and  oisk  based  ooeration.  The 
disks  are  used  for  scratch  files. 

a This  process  keeos  track  of  the  transactions  processed  or  not  processed  in  the  last 
90  days.  It  provides  an  audit  trail  and  a data  base  for  statistics  and 
responding  to  foUow-uo  inquiries. 

• This  process  must  be  run  once  every  24  hours  and  as  well  generates  daily, 
weekly  and  monthly  reports,  but  can  be  put  on  t.he  current  config*arat;on  .?nd 
processed  by  an  improved  scnedulmg  procedure. 

•DLSC,  Request  for  5673Q  Souioment  Augnientfltion,  23  Octooer  19T6. 
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Secondary  B6700  - Workload  Scheduling  Improvements 

Action  17.  Improve  the  Scheduling  of  Jobs  on  the  Secondary  B67Q0 

Actions  16  and  17  are  interdependent.  The  purpose  of  Action  16  is  to  remove 
the  current  bottleneck  on  the  Secondary  B6700  by  adding  core  memory.  No  additional 
mass  storage  devices  are  proposed.  AU  the  applications  either  on,  or  to  be  transferred  to, 
the  Secondary  B6700  will  fit  on  the  current  configuration,  but,  in  most  instances, 
concu'^rent  processing  wiU  not  be  possible.  Since  virtually  all  of  the  workload  on  the 
Secondary  B6700  is  periodic  in  nature,  it  must  be  effectively  scheduled  and  the  system 
efficiently  operated.  Tapei.  and  disk  packs  will  hu'  J to  be  mounted  and  dismounted,  but 
this  is  a common  practice  in  job  shop  environments. 

Application  Program  Management 

For  a large-scale  computer  system  such  as  BIDS,  with  some  525  application 
programs,  management  of  applications  is  essential.  Such  an  effort  would  build  upon 
existing  DLSC  efforts. 

Action  18.  Improvement  Application  Program  Design  Review 
and  Maintenance 

The  focus  of  Action  18  is  on  quality  and  satisfaction  of  requirements.  The  aim 
is  to  detect  program  errors  and  inefficiencies,  and  to  support  the  development  of 
programming  standards  and  program  control.  This  action  would  expand  on  efforts  by  the 
DLSC  Optimization  Task  Group,  standard  documentation  products,  and  acceptance  testing 
procedures. 

DLSC  should  institute  software  design  reviews  to  improve  communication 
among  users,  programmers  and  managers,  and  to  minimize  the  suboptimal,  incremental 
solution  process.  Such  reviews  are  working  sessions  in  which  the  programs  are  reviewed 
by  those  who  have  an  interest  in  that  product.  Typically,  the  review  team  includes  an 
"outside"  professional  (an  experienced  programmer  or  systems  analyst  within  DLSC). 
designers  (programmers)  of  the  program  under  review,  the  user  of  the  program  product. 


and  other  designers  whose  programs  interface  with  the  program  under  review.  These 
design  reviews  have  two  objectives:  to  assess  the  quality  of  the  program  and  its 
effectiveness  in  meeting  specified  requirements.  The  review  should  be  systematic  and 
well  documented  to  establish  an  audit  trail  for  subsequent  reviews.  The  design  reviews 
are  carried  out  in  addition  to  the  daily  quality  controls  instituted  by  the  chief 
programmer,  and  should  be  performed  only  at  carefully  selected  milestones,  such  as  at  the 
completion  of  the  preliminary  design. 

Reviews  conducted  by  competent  professionals  (outsiders)  have  resulted  in  the 
early  detection  of  program  design  deficiencies,  reduced  downstream  maintenance,  and 
high  quality  products.  One  technique  currently  used  for  these  reviews  is  the  systems  or 
structured  walk-through  method. 

Action  19.  Improve  Implementation  of  Software  Refinements 

A number  of  useful  program  improvements  have  been  identified  by  the  DLSC 
Optimization  Task  Group.  However,  many  of  the  recommendations  have  not  yet  been 
implemented,  either  to  correct  operating  programs  or  to  improve  new  program 
development.  The  focus  of  this  action  is  on  the  implementation  of  corrections  of  detected 
program  deficiences,  and  the  formal  feedback  of  the  impact  of  the  change. 

EDP  Workload  Planning  and  Forecasting 

Due  primarily  to  the  brevity  of  the  task  schedule,  it  was  necessary  to  utilize  the 
DIDS  workload  projections  developed  by  DLSC  based  on  processing  requirements  in  wall 
clock  hours.  As  noted  in  the  analysis  of  the  workload  transferable  from  the 
Primary  B6700  to  the  Secondary  B6700,  wall  clock  hours  are  not  an  appropriate  measure 
of  workload  throughput  or  capacity  of  multiprogramming,  multiprocessing  systems. 

The  estimation  of  the  capacity  of,  and  throughput  for  a multiprogramming, 
multiprocessing  system  can  be  very  complicated,  and  a discussion  of  the  many  potentially 
relevant  considerations  is  beyond  the  scope  of  this  task.  However,  for  those  systems 
where  the  processor  is  the  limiting  resource  (the  Primary  B6700  and  possibly  the 
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augmented  Secondary  B6700)  processor  hours  are  a reasonable  surrogate  for  EDP  system 
capacity. 


By  processor  hours,  we  mean  the  amount  of  time  the  CPUs  are  actively  processing  a 
program.  For  the  Primary  B6700  multiprocessors,  the  processor  hours  for  a program  are 
dramatically  different  from  the  wall  clock  hours,  which  measure  approximately  the 
amount  of  time  the  program  resides  in  the  system.  In  the  course  of  this  analysis,  we 
observed  ratios  of  processor  hours  to  wall  clock  hours  for  specific  programs  of  1:2  to  1:10 
in  the  Primary  B6700.  In  the  workload  projections,  the  estimates  in  wall  clock  hours 
reflect  various  multiples  of  processor  hours  for  different  applications.  The  result  is  that 
the  annual  aggregated  estimates  yield  awkward  and  hypothetic  daily  averages  for 
workload  required  and  capacity  (maximum  production  hours)  available.  Examples  are 
40.4  hours  of  machine  production  time  available  per  Primary  B6700  CPU  per  "day," 
26.8  hours  of  machine  production  time  available  per  Secondary  B6700  CPU  per  "day,"  and 
, 54.4  hours  of  machine  production  time  available  for  the  IBM  360/65J  CPU  per  "day." 

Wall  clock  hours  can  indicate  workload  volume  and  machine  capacity,  but  they  are 
rough  estimates,  meaningful  only  if  the  workload  mix,  software  and  application  programs 
do  not  vary,  or  to  provide  a rough  estimate  of  the  job  turnaround  time  for  a system 
customer.  For  the  BIDS  situation,  we  judge  that  wall  clock  hours  are  too  imprecise  and 
require  too  many  untenable  assumptions  to  be  useful  for  workload  planning  and 
' forecasting. 

Action  20.  Improve  DIPS  Workload  Planning  and  Forecasting 
Based  on  this  analysis,  processing  hours  are  a more  appropriate  measure  of 
both  workload  and  machine  capacity  for  the  BIDS  EBP  systems.  This  is  clearly  true  for 
r the  Primary  B6700  and,  at  the  very  least,  more  correct  than  wall  clock  hours  for  the 

I Secondary  B6700  and  IBM  360/65J. 

I Bata  are  available  to  make  the  BIBS  workload  and  EBP  processor  iiour 

L computations.  Two  sources  are  the  BIBS  Monthly  Summary  of  Job  Elapsed  Processing 
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Requirement  Reports  and  the  SPARK/LOGSTATISTICS,  Total  Processor  Time  and 
Program  Exception  Reports. 

With  the  workload  and  EDP  capacity  estimates  expressed  in  terms  of  processor 
hours,  the  projections  and  EDP  surplus  or  deficit  capacities  can  be  assessed  more 
precisely.  This  would  be  particularly  useful  for  smoothing  the  workload,  identifying 
transferable  work  and  for  sizing  future  augmentations. 
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IMSTAl.;jkriONS  ANO  I,a44mcs 


TASK  ORDER  SD-321-62 
(TASK  77-5) 


DATE: 


11  Januarv  1?‘ 


1.  Pursuant  to  Articles  E-1  and  E-3  cf  the  Oeparfrent  of  Defense 
Contract  No.  S0-32I  with  the  Logistics  h:anagerrent  Institute  (L.hl),  the 
Institute  is  requested  to  undertake  the  following  task: 

A.  T I TIE : OIOS  Computer  System  Evaluation 

B.  BACKGROUND: 

(l)  The  Defense  Integrated  Data  System  (DIDS)  is  a large- 
scale,  centralized,  mul t i -processor  data  processing  system  that  utilize 
a functionally  integrated,  random-access  data  base  in  excess  of  five 
billion  characters  and  processes  three  million  transactions  monthly. 
DIDS  Is  designed  to  provide  logistics  data  services  to  supoort  logistic 
managers  in  nine  functional  areas:  cataloging,  item  utilization  arc 

marketing,  i nterchangeab i 1 i ty  and  substitutability,  suoply  management. 
Military  Standard  Item  Character i st i cs  Coding  Structure  (MILSTICCS), 
publications,  provisioning,  item  entry  control  and  screening,  and 
statistics. 


(2)  The  hardware  and  software  design  and  development  of' 
DIDS  were  initiated  in  1965  and,  though  close  to  completion,  the 
system  is  still  in  the  process  of  being  implemented. 

(3)  Overall  resocns i b i 1 i ty  for  DIDS  resides  In  the  Office 
of  the  Assistant  Secretary  cf  Defense  (Installations  and  Logistics) 
where  both  policy  and  guidance  are  develcoed  and  Issued.  Authority  for 
the  development  and  imo I ementat icn  cf  DIDS  has  been  delegated  to  tne 
Defense  Suoply  Agency,  which  In  turn  has  made  the  Defense  Logistics 
Services  Center  (DLSC)  responsible  for  the  develooment  anc  design  of 
DIDS,  and  tne  development,  coo'C i nat i on , and  maintenance  of  its 
operating  procedures.  Close  ties  with  the  Military  Departments, 

General  Services  Adm i n i s t ra t ion , and  Department  of  Transocrtat i on 

are  maintained  for  monitoring,  executing,  anc  interfacing  activities. 

(k)  Over  the  past  year  there  !^as  ceen  crewing  cercer- 
over  DIDS  efficiency  anc  capacity.  Both  harewa'*®  augmentation  and 
software  cpt  imi  zat  icn  nave  been  utilized  to  acnieve  I -c  rove'-en  t s . 
Notwithstanding  these  efforts,  DIDS  still  Is  net  achieving  ' ts 
planned  goals. 


C.  GSJECTl  Vi : To  cerforTi  3 DIGS  computer  system  perform- 

ance evaluation  to  assess  whether  additional  hardware  is  neeced  or 
whether  the  present  hardware  is  adequate  but  must  be  utilized  more 
effectively  to  process  the  existing  and  planned  workload. 

D.  SCOPE  OF  WORK:  In  performing  this  work  the  LMI  will  draw 

upon  the  current  DiOS  design,  plan,  documentation  and  evaluation  of 
reports.  Interviews  with  selected  DISC  personnel  will  be  Included,  as 
will  on-site  gathering  of  required  data.  The  focus  of  the  analysis 
will  be  on : 


(1)  Oetermining  whether  the  current  hardware  configuration 
has  the  capacity  to  process  the  existing  and  projected  near-term  work- 
load; 

(2)  Assessing  the  efficiency  of  the  current  software 
(both  for  the  B67QO  operating  system  and  applications  programs)  and 
the  file  des ign; 

(3)  Preparing  a basic  conversion  and  implementaticn  plan 
to  correct  the  deficiencies  in  the  hardware  and  software;  and 

(4)  Assessing  the  cost  effectiveness  of  optimizing  the 
existing  Autor,;atic  Data  Processing  system  versus  expanding  its  hardware 
configuration. 

Lhl  will  utilize  consultants  as  required  to  achieve  the 
appropriate  mix  of  skills. 

2.  SCHEDULE : The  task  will  be  completed  with  submission  of  a 

final  report  by  23  February  1977. 


DATE: 
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APPENDIX  B 


DIDS  WORKLOAD  PROJECTION  UNCERTAINTY  AND 
IMPLICATIONS  FOR  THE  STUDY  FINDINGS 


A central  assumption  in  the  analysis  was  that  the  DLSC/DLA  DIDS  workload 
projection  prepared  in  December  of  1976  was  an  accurate  representation  of  future  DIDS 
demand  requirements.  Based  on  that  projection,  if  the  December  1977  workload  levels 
could  be  satisfied,  so  could  the  workload  throughout  1978  and  1979.  We  still  feel  that  the 
optimization  and  limited  augmentation  proposed  as  Option  5 in  the  report  is  correct  and 
adequate  for  this  projection.  With  a deliberate  and  intensive  assignment  of  critical 
resources,  the  necessary  optimization  improvements  are  possible. 

Since  the  study  was  performed,  it  has  been  pointed  out  by  DLSC  and  DLA  that  their 
December  1976  DIDS  workload  projection  was  not  complete.  A considered  estimate  of  an 
additional  10%  for  the  December  1977  levels  was  made  by  DLSC/DLA,  and  a growth  of  4% 
to  5%  per  annum  for  the  years  1978  through  1980  was  anticipated.  This  prospect  of  a 
burgeoning  workload  increasing  montonically  at  5%  per  annum,  coupled  with  an 
uncertainty  factor  of  plus  10%  for  December  1977,  results  in  a 20%  plus  difference  for  the 
December  1979  workload  level  assumed  in  the  study. 

If  this  estimate  of  a greater  workload  is  more  realistic,  then  Option  5 can  only 
provide  short-term  relief.  If  we  refer  to  Option  5 as  Part  1 of  a larger  and  long-term 
plan,  then  it  can  be  viewed  as  a contribution  to  Part  2 of  the  strategy  to  augment  the 
DIDS  computer  system. 

This  long-term  (Part  2)  strategy  assumes  the  following  actions:  first,  that  the 
recommended  augmentation  and  optimization  takes  place  for  short-term  relief,  and, 
second,  that  DLA/DLSC  prepare  a comprehensive  five-year  DIDS  workload  projection  in 
terms  of  monthly  increments  for  the  next  calendar  year,  and  quarterly  increments  for  the 
subsequent  four  years.  This  workload  projection  should  include:  DIDS  functions. 


frequency  of  operation,  estimated  processor  time,  estimated  I/O  times  (note  that  wall 
clock  hours  are  not  acceptable  measures),  growth  rates,  and  uncertainty  (displayed  in 
terms  of  a + range  for  a 90%  to  95%  confidence  interval). 

Based  on  the  new  workload  projection  and  the  determination  that  there  is  sufficient 
cause  for  additional  hardware  capacity,  then  the  augmentation  described  as  Option  3 or  its 
cost-effective  equivalent  should  be  pursued,  given  that  the  necessary  Federal  require- 
ments are  satisfied. 

The  augmentations  as  described  in  the  study  maintain  full  compatibility  with  the 
existing  system  for  minimal  conversion  and  implementation  costs  and  time,  and  also 
incorporate  the  potential  for  additional  growth.  They  consist  of  integrating  the 
Primary  B6700  and  Secondary  B6700  via  a Burroughs  Global  Memory  with  a B6800  single 
CPU  system.  In  this  configuration,  all  three  systems,  consisting  of  six  CPUs  (three  on  the 
Primary  B6800,  two  on  the  Secondary  B6700,  and  one  on  the  B6800)  can  have  access  to  the 
TIR.  Depending  on  the  size  of  the  B6800  selected,  the  configuration  will  at  least  more 
than  double  the  capacity  of  the  current  DLSC  DIDS  workload  processing  potential. 
Assuming  that  both  B6700  systems  are  retained,^  and  depending  on  the  size  of  the  B6800 
Global  Memory  selected,  this  augmentation  is  estimated  to  cost  between  $1,104,000 
and  $1,768,000.  For  either  of  these  configurations,  a 16-month  lead  time  is  estimated. 

A concerted  effort  is  clearly  needed  to  determine  the  long-term  (10  to  15  years) 
expected  growth  for  the  DIDS  workload.  Whether  or  not  ceilings  should  be  placed  on 
certain  functional  volumes,  what  should  be  done  about  inactive  items,  and  what  effect  the 
expected  foreign  military  sales  will  have  are  all  important  questions.  An  analysis  of  these 
matters  would  be  based  on  the  five-year  workload  forecast  called  for  above  and  have  as  an 
objective  the  provision  of  a comprehensive  DIDS  growth  strategy  and  management  plan 
for  DLSC,  DLA  and  OSD. 

^Given  that  a B6800  is  rated  at  2 1/2  times  the  processing  capability  of  the  B6700,  a 
special  determination  should  be  made  to  keep  or  trade  the  Secondary  B6700.  It  could  still 
be  used  as  a test  bed  when  connected  to  the  Global  Memory. 
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^ In  summary,  we  still  recommend  the  short-term  augmentation  and  optimization 

strategy  outlined  as  Option  5 in  the  report.  The  expected  hardware  expenditures  for  the 
augmentation  under  Option  5 are  $350,000  to  $400,000  in  1977  dollars.  If  the  expected 
workload  growth  trends  materialize,  a subsequent  augmentation  will  be  required.  In  this 
event,  the  recommendations  for  Option  5 can  be  viewed  as  a Part  1 of  the  overall 
computer  resources  augmentation  plan.  A candidate  for  Part  2 could  consist  of  adding 
selected  Burroughs  hardware  to  be  available  in  early  1978,  and  integrating  all  the  DLSC 

» 

Burroughs  computer  systems  with  a B6800  via  a Global  Memory  device.  This 
augmentation  can  be  expected  to  cost  between  $1,104,000  to  $1,768,000  in  1977  dollars. 
That  augmentation  or  its  cost-effective  equivalent  must  be  preceded  by  Part  1 and,  most 
I ) importantly,  a comprehensive  five-year  BIDS  projection  of  BIDS  workload  must  be 

I prepared. 
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